Comments 17
1. мы только что создали объектно ориентированную модель нашей реляционной базы
Нет, не создали. ParentCategoryId к объектно-ориентированной модели не имеет отношения.
Либо ParentCategory, либо, что для данного примера нагляднее, ChildCategories.
2. Биндинги руками — зачем? Это можно сделать вообще на чистом XAML.
Даже переключение можно, хотя тут я бы всё-таки сделал руками.
3. Но зачем вообще переключение? Не проще ли XML загрузить в те же POCO?
4. Мелочь, но вместо прямого биндинга к SelectedItem, я бы где можно использовал IsSynchronizedWithCurrentItem + биндинг к /.
Нет, не создали. 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. :)
Сгенерированный в проекте 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 будет универсальным.
POCO = простой класс. Проще говоря, можно загрузить XML в нормальном виде (Category), и тогда UI будет универсальным.
>То, что Linq сгенерил класс по базе не делает этот класс ООП
.Net — это Объектно Ориентированное Программирование (ООП) и всё, что в нём есть является объектами.
>С тем же успехом можно было бы сгенерить struct. Отличие результата работы ORM от типизированного датасета именно в возможности отразить на базу объектную модель, включая наследование и коллекции. Наследование в этом примере не нужно, а коллекции вполне. Кстати Linq-to-Sql умеет One-to-Many по умолчанию.
Честно говоря, я не понимаю к чему Вы это пишете… Возможно, что у меня не хватает сообразительности, чтобы понять Вас.
>POCO = простой класс. Проще говоря, можно загрузить XML в нормальном виде (Category), и тогда UI будет универсальным.
Этого я так же не понял. Что Вами понимается под «нормальным видом», а так же под «универсальностью»?
.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 или любой другой, для того, чтобы она могла выйти на главную хабра
Было бы приятно видеть еще на gotdotnet.ru :)
Статья хорошая, спасибо. Успехов и следующих публикаций вам :)
То что не всюду идеально — здесь неважно.
PS: Ресурс для скачивания не того :)
Может быть, на dropbox, sky или другой ресурс перенесете?
То что не всюду идеально — здесь неважно.
PS: Ресурс для скачивания не того :)
Может быть, на dropbox, sky или другой ресурс перенесете?
>Статья хорошая, спасибо. Успехов и следующих публикаций вам :)
Спасибо. :)
>PS: Ресурс для скачивания не того :)
Может быть, на dropbox, sky или другой ресурс перенесете?
Т.е. исходники/библиотека не скачиваются? Про dropbox и sky не слышал ранее. Установил dropbox, как только разберусь с ним — обновлю линки.
Спасибо. :)
>PS: Ресурс для скачивания не того :)
Может быть, на dropbox, sky или другой ресурс перенесете?
Т.е. исходники/библиотека не скачиваются? Про dropbox и sky не слышал ранее. Установил dropbox, как только разберусь с ним — обновлю линки.
Скачиваются, но там порнуха грозная такая. Как то с тематикой не вяжется.
Dropbox — дело полезное.
А это SkyDrive — вам может быть как MS девелоперу интересней будет.
cid-e2c74bd07b6f9fff.skydrive.live.com/self.aspx/.Public/TreeStructureBrowse.rar — Вот ваш архив в своем MS аккаунте для примера выложил. Сейчас как раз разбираюсь с хитросплетениями VS+Expression :)
Dropbox — дело полезное.
А это SkyDrive — вам может быть как MS девелоперу интересней будет.
cid-e2c74bd07b6f9fff.skydrive.live.com/self.aspx/.Public/TreeStructureBrowse.rar — Вот ваш архив в своем MS аккаунте для примера выложил. Сейчас как раз разбираюсь с хитросплетениями VS+Expression :)
//*
хотя в реальной работе, конечно же следует вести диалог с базой данных только через хранимые процедуры, дабы избежать возможности выполнения sql-инъекций
*//
Да чо уш там, все запросы к бд -> письмом к дба — ответы распарсивать и показывать пользователю/
А понятия о ОРМ судя по вашему тексту простираются еще дальше…
1й или 2й курс универа?
хотя в реальной работе, конечно же следует вести диалог с базой данных только через хранимые процедуры, дабы избежать возможности выполнения sql-инъекций
*//
Да чо уш там, все запросы к бд -> письмом к дба — ответы распарсивать и показывать пользователю/
А понятия о ОРМ судя по вашему тексту простираются еще дальше…
1й или 2й курс универа?
Sign up to leave a comment.
Отображение иерархической структуры данных в WPF с помощью привязки и шаблонов