Pull to refresh

Comments 17

1. мы только что создали объектно ориентированную модель нашей реляционной базы
Нет, не создали. ParentCategoryId к объектно-ориентированной модели не имеет отношения.
Либо ParentCategory, либо, что для данного примера нагляднее, ChildCategories.

2. Биндинги руками — зачем? Это можно сделать вообще на чистом XAML.
Даже переключение можно, хотя тут я бы всё-таки сделал руками.

3. Но зачем вообще переключение? Не проще ли XML загрузить в те же POCO?

4. Мелочь, но вместо прямого биндинга к SelectedItem, я бы где можно использовал IsSynchronizedWithCurrentItem + биндинг к /.
>Нет, не создали. ParentCategoryId к объектно-ориентированной модели не имеет отношения.

Сгенерированный в проекте Linq2Sql код — это своего рода ПРОЕКЦИЯ на реляционную базу данных, т.е. её ОБЪЕКТНО ОРИЕНТИРОВАННАЯ «проекция»… Поэтому наличие ParentCategoryId вполне логично и необходимо. Важно то, что сгенерированный с помощью LINQ 2 SQL набор классов позволяет использовать привычное Объектно Ориентированное Программирование при работе данными реляционной модели. Возможно я выразился не столь ясно, как следовало, но всё же полагаю, что ход моих мыслей ясен.

>Биндинги руками — зачем? Это можно сделать вообще на чистом XAML

Часть биндингов мною выполнена как раз в XAML-разметке (как Вы можете заметить). В код мною вынесена ЛОГИКА, при которой привязки ПЕРЕНАЗНАЧАЮТСЯ при выборе пользователем иного источника данных.

>Но зачем вообще переключение? Не проще ли XML загрузить в те же POCO?

Я не знаком с POCO, и если это то, о чём я подумал (см. линк), то совершенно не понимаю, каким образом он тут нужен (я пишу не на C++, а на C#, т.е. всё выше приведённое — управляемый код).

>Мелочь, но вместо прямого биндинга к SelectedItem, я бы где можно использовал IsSynchronizedWithCurrentItem + биндинг к /.

Согласен, но это — альтернатива. Если бы я написал через IsSynchronizedWithCurrentItem, кто-то мог бы с таким же успехом предложить и вариант с SelectedItem. :)

То, что Linq сгенерил класс по базе не делает этот класс ООП — по сути дела в таком примере это просто структура данных. С тем же успехом можно было бы сгенерить struct. Отличие результата работы ORM от типизированного датасета именно в возможности отразить на базу объектную модель, включая наследование и коллекции. Наследование в этом примере не нужно, а коллекции вполне. Кстати Linq-to-Sql умеет One-to-Many по умолчанию.

POCO = простой класс. Проще говоря, можно загрузить XML в нормальном виде (Category), и тогда UI будет универсальным.
>То, что Linq сгенерил класс по базе не делает этот класс ООП

.Net — это Объектно Ориентированное Программирование (ООП) и всё, что в нём есть является объектами.

>С тем же успехом можно было бы сгенерить struct. Отличие результата работы ORM от типизированного датасета именно в возможности отразить на базу объектную модель, включая наследование и коллекции. Наследование в этом примере не нужно, а коллекции вполне. Кстати Linq-to-Sql умеет One-to-Many по умолчанию.

Честно говоря, я не понимаю к чему Вы это пишете… Возможно, что у меня не хватает сообразительности, чтобы понять Вас.

>POCO = простой класс. Проще говоря, можно загрузить XML в нормальном виде (Category), и тогда UI будет универсальным.

Этого я так же не понял. Что Вами понимается под «нормальным видом», а так же под «универсальностью»?
>>POCO = простой класс. Проще говоря, можно загрузить XML в нормальном виде (Category), и тогда UI будет универсальным.
>Этого я так же не понял. Что Вами понимается под «нормальным видом», а так же под «универсальностью»?

Думаю, имеется ввиду, что если грузить из базы и из XML в объекты одного типа, то UI будет одинаков для обоих случаев.
Вы же для базы используете одну структуру обяъектов, для XML — XElement, поэтому пришлось описывать 2-а варианта UI. Страшно представить, что будет если придтся читать ещё из текстовых файлов и получать от Веб-сервиса…
В примере я СПЕЦИАЛЬНО использовал разные типы данных, дабы показать, как данная проблема решается с помощью XAML-шаблонов. Конечно можно было бы динамически упаковывать данные в объекты одного и того же типа и это сильно упростило бы код, но тогда я не смог бы более развёрнуто показать тот момент, что данные вовсе не обязаны иметь один и тот же тип, поскольку данную проблему берут на себя решать XAML-шаблоны.
спасибо за статью, перенесите ее пожалуйста в блог .net или любой другой, для того, чтобы она могла выйти на главную хабра
Переношу в блог WPF.
Так ведь на хабре условие — публикация только в одном месте. :)
Внимательнее прочитайте правила: Не нужно копировать свои посты из других блогов и сайтов, указывая, что ранее они были опубикованы в другом месте.
Статья хорошая, спасибо. Успехов и следующих публикаций вам :)
То что не всюду идеально — здесь неважно.

PS: Ресурс для скачивания не того :)
Может быть, на dropbox, sky или другой ресурс перенесете?
>Статья хорошая, спасибо. Успехов и следующих публикаций вам :)

Спасибо. :)

>PS: Ресурс для скачивания не того :)
Может быть, на dropbox, sky или другой ресурс перенесете?

Т.е. исходники/библиотека не скачиваются? Про dropbox и sky не слышал ранее. Установил dropbox, как только разберусь с ним — обновлю линки.
Скачиваются, но там порнуха грозная такая. Как то с тематикой не вяжется.
Dropbox — дело полезное.
А это SkyDrive — вам может быть как MS девелоперу интересней будет.
cid-e2c74bd07b6f9fff.skydrive.live.com/self.aspx/.Public/TreeStructureBrowse.rar — Вот ваш архив в своем MS аккаунте для примера выложил. Сейчас как раз разбираюсь с хитросплетениями VS+Expression :)

Исправил ссылку. Вспомнил, что у меня тоже есть Windows LiveId, а следовательно и SkyDrive. :)
//*
хотя в реальной работе, конечно же следует вести диалог с базой данных только через хранимые процедуры, дабы избежать возможности выполнения sql-инъекций
*//
Да чо уш там, все запросы к бд -> письмом к дба — ответы распарсивать и показывать пользователю/

А понятия о ОРМ судя по вашему тексту простираются еще дальше…

1й или 2й курс универа?
Вы чушь какую-то написали…
Sign up to leave a comment.

Articles