bdfyyТакой вопрос: по правильному, если не использовать ORM, запросы к базе должны выполняться на уровне модели?Нет, на уровне конкретной реализации репозитоия
А это обычно data layer (data access layer, data mapping layer). Но если хотите по быстрому, можете и в модель запихать.

Приложения WPF с шаблоном проектирования MVVM. Модель данных и репозиторий.
Джош СмитДанные должны откуда-то приходить и где-то храниться. В этом приложении экземпляр класса CustomerRepository загружает и хранит все объекты Customer. Так получилось, что он загружает данные клиентов из файла XML, но вообще
тип внешнего источника данных несущественен. Данные могу поступать из базы данных, веб-службы, именованного канала, файла на диске или от почтовых голубей: это просто не имеет значения.
Если у вас есть объект .NET с данными, независимо от того, откуда они, шаблон MVVM может вывести эти данные на экран.

user7320Я в button1_Click всегда делаю - работает! ))Тро-ло-ло. батон клик в WPF, пошутил, так пошутил
user7320Из-за старости это уже во многом вредная статья. Её править и улучшать давно надо. Например, про этот самый ORM не сказано. Я раньше, как дурак, делал репозиторий поверх ORM, сгенеренной EF.Дак так и надо. И раньше и сейчас.

P.S.: иногда лучше жевать, чем говорить.

bdfyyСпасибо!

skyANAНет, на уровне конкретной реализации репозитоия
А это обычно data layer (data access layer, data mapping layer). Но если хотите по быстрому, можете и в модель запихать.
Значит правильно мыслюА как именно: в сторону data layer или "по быстрому"?

bdfyy- в какой момент ORM обычно обновляет данные в модели, если приложение многопользовательское. т.е. несколько пользователей используют один и тот же набор объектов (например, подгруженных из БД), один изменил объект, когда узнают остальные клиенты.После вызова метода Refresh :) О какой ORM речь?
bdfyy- как обычно организовывается работа с объектом в разных окнах, одного приложения. Окна могут быть показаны в разной последовательности или одновременно. Хочется иметь один экземпляр модели для обоих окон или это не верно? (вопрос наверно не для этой ветки)Хотите - имейте. Можете реализовать Registry (Реестр) , а можете по простому.

user7320Если Скайана имел ввиду ещё и свой репозиторий с конкуренцией и прочими плюшками, то я не зря сказал, что "я как дурак реализовывал". Тут тема недавно была по обсуждению своего репозитория, из которой я вынес вывод, что для простых и даже средних приложений ORM, создаваемое EF, вполне сойдёт за репозиторий. А если по-нормальному реализовывать, то это "не для средних умов". В смысле, опыт нужен, и вообще. Если что, классы ORM у EF являются частичными (парциальными), так что можно дописать свою функциональность в других файлах, не боясь, что при перегенерации ORM весь ваш код будет потерян.

А у Джоша Смита приведён пример репозитория ну очень простого. Такого, который в реальной жизни не нужен, т. к. даже хуже энтитифреймворковского ORM. Это у него была такая "затычка", т. к. цель-то была не про репозиторий рассказать, а про MVVM. Для реализации репозитория есть спецстатьи, которые обычно объединяются с шаблоном Unit Of Work и т. д. И опять же, там обычно всё сильно просто. Настолько, что ORM от EF с возможностью дописывания парциальных классов опять тут может служить вполне нормальной заменой, а чаще всё равно превосходит по возможностям.

Так что или писать нормально (на что у вас уйдёт больше месяца, и то, если вы с опытом), или пока забыть о самописных и пользоваться готовыми ORM.Запомни. ORM - это не репозиторий! Тупо по определению.
Ты своими рассуждениями только вводишь неопытных разработчиков в заблуждение.

bdfyyskyANA...О какой ORM речь?
В том-то и беда что придется самому писать эти механизмыКакие механизмы? Опишите задачу.
bdfyyskyANA... а можете по простому.
это как?Держать модель в памяти, а во View, где требуется работать с её частью, отдавать эту часть по ссылке.

Если Вы объясните, что за Окна и в какой последовательности они могут открываться, то можно будет что-то сказать конкретнее.

user7320, и для кого я выделял текст , спрашивается.Джош СмитДанные должны откуда-то приходить и где-то храниться. В этом приложении экземпляр класса CustomerRepository загружает и хранит все объекты Customer. Так получилось, что он загружает данные клиентов из файла XML, но вообще
тип внешнего источника данных несущественен. Данные могу поступать из базы данных, веб-службы, именованного канала, файла на диске или от почтовых голубей : это просто не имеет значения.
Если у вас есть объект .NET с данными, независимо от того, откуда они, шаблон MVVM может вывести эти данные на экран.Репозиторий реализует прозрачную работу с данными, которые чёрт знает как могут быть распределены. ORM этого не умеет, это тупо object-relational mapping c дополнительными плюшками.

Вот скажите как реализовать простой репозиторий Джоша Смита, что загружает данные клиентов из файла XML, средствами EF?

bdfyyЕсть проект написанный на связке: Delphi + FireBird. Написан по старинке, без ORM с прямыми запросами к БД в окнах.
По разным причинам принято решение Delphi "сменить" на WPF от Микрософта. Базу трогать нельзя, совместимость.

Пробовал натравить на базу EF он вешается, т.е. сгенерить до конца не может. Да и в сгенеренном много чего не хватает.
Все усугубляется тем, что объекты хранимые в таблице могут выступать как схожими так и разными.
Поясню: Есть таблица А и В. В таблице А хранится объект АА, в таблице В объекты ВА и ВВ. Объект ВА может быть контейнером для ВВ, но при этом объект АА может быть контейнером для обеих объектов ВА и ВВ. И с точки зрения объекта АА между объектами ВА и ВВ нет разницы. Причем объекты ВА и ВВ могут хранится в разных базах, которые могут редактироваться независимо в разных местах.
Как натравить NHibernate на базу не понял. По любому понял (на моем уровне знания данных ОRM), что придется многое допиливать руками.

По поводу клиента. Объекты ВА и ВВ могут быть соответственно отображены скопом, например в виде таблицы, или в виде зависимости какой нибудь графической схемой. Эти окна абсолютно не связаны с точки зрения использования. т.е. один клиент может редактировать только в одном окне, другой только в другом, а третий в обеих окнах сразу.

Все это конечно упрощенно. Надеюсь, что нормально объяснил. Готов добавить пояснения еще. Спасибо.Что за A и B, предметная область что-ли секретная?

Ну да ладно. То есть имеем некую древовидную (компонентную) структуру, когда узел (компонент) AA содержит в себе набор дочерних узлов (компонентов) BA и BB, или что означает "объект АА может быть контейнером для обеих объектов ВА и ВВ"?

И Вы не озвучили проблему: какие механизмы не получается реализовать?

user7320У меня с этой штукой тоже проблемы идентификации. Если БД почти полностью моделирует предметную область - сущности и связи - то получается, что модель будет повторять эту БД. А тогда уже получается, что лучше не городить свою модель со связями, а использовать ORM от EF - там уже всё намоделировано в классах и связано наилучшим образом. Остаётся только расширить эту модель предметной области функциональностью (расчёты там и прочее) - и то, если этой функциональности не заложено в БД в виде там процедур или ещё чего - и вот вам нормальная модель из ORM. Я прав, нет? Ну реально нет смысла "хранить в себе копию БД".Не хочешь, не городи. Не видишь смысла, не храни. Когда через год наткнёшься на грабли, тогда и поймёшь.

user7320МСУСцуко, сколько же от 7320 букаф... Просто невозможно курить этот поток сознания
У меня много проблем. Я пытаюсь их все сразу решить...Купи книжку по DDD.

user7320, а покажи как у тебя отображается ProductType в Object Browser.