Сейчас читаю про EF CF. Если там можно поставить атрибут NotMappedAttribute, то, по аналогии с WCF и с ASP.NET MVC (там тоже можно расставлять атрибуты, которые исключают поля или методы из контекста WCF или ASP.NET MVC, соответственно), можно написать классы, которые не только для создания БД будут годны, но и как полноценная модель в контексте MVVM. А?

А то раньше как бывало: создаёшь БД в дизайнере, потом натравливаешь на неё EF и создаёшь edmx, потом создаёшь "трио" MVVM. И вот в этом трио модель ну просто почти один в один повторяет файлы POCO, созданные EF. Разве что функциональности предметной области в этих POCO нет. Так вот, чтобы не плодить сущности, какой у кого опыт использования EF CF моделей в качестве MVVM моделей? Или думаете, что слишком много путаницы возникнет в такой объединённой модели - где там БД-часть, а где - предметной области?

А то у некоторых DBA возникает соблазн впихнуть предметную область в БД - на хранимках там функциональность написать и т. п. А мы, кодеры, чем тогда хуже?

Shocker.Pro,

а зачем напрягать и дёргать? В модели представления вы можете сделать свойство, обращающееся ко свойству модели. И при этом ничего из БД дёргаться не будет. Ведь к БД обращение идёт только через контекст. А если вы просто обратитесь к свойству Blog.Name (возьмём пример отсюда ), то БД не дёрнется.

Или что вы имели ввиду?

Shocker.ProКроме того, обычно в презентационном слое нужны не целиком модели, а некоторые поля, надерганные из связанных моделей. Так зачем тогда напрягать БД и дергать постоянно модели (или даже деревья) целиком (как раз в большом проекте возросшая в разы нагрузка на БД будет более заметна)
Если презентатор (модель представления) набирается из нескольких полей разных моделей, то при обратном - когда надо такую модель представления сохранить в БД - эта модель представления разбирается обратно на составляющие её модели и сохраняется в БД с учётом зависимостей. Разве не так? По-другому как вы можете новую сущность - модель представления - не имеющую аналога в БД и в модели, сохранить в БД?

Shocker.ProА что, модель не будет сохраняться в БД? Тогда причем тут EF?

А если будет, то как вы получите актуальное свойство Blog.Name, не обращаясь к БД?
Если Blog.Name имеет отображение на БД, то да, запрос в БД надо делать в любом случае - что с моим подходом, что когда модели разделяются. Если Blog.Name не имеет отображение на БД, то в моём подходе ставим атрибут NotMappedAttribute. Но тогда и в моём подходе, и в подходе с разделением моделей значение Blog.Name откуда-то должно быть получено, так? Но тогда снова нет разницы в подходах в отношении свойства Blog.Name - назначайте его как вам угодно, только не в контексте БД.

В чём проблема? Я просто пока не делал этого на практике, вот и хочу узнать, в чём проблема.

Вроде, действия в обоих подходах одинаковые, но в моём только один набор классов моделей, а в подходе с разделением моделей - их два.

Я могу сказать, что мой подход плох, только когда модель для БД и модель предметной области сильно различаются. Но такой случай, по-моему, может быть только если типы данных совсем уж не совпадают, или если в БД надо сохранять совсем уж небольшую часть модели предметной области. Но во втором случае не вижу проблемы просто проставить побольше атрибутов NotMappedAttribute.

Ну да, будет модель завалена атрибутами из DataAnnotations - а и так в больших проектах по 3-5 атрибутов на каждом свойстве висит.

Shocker.ProСущности создаются и сохраняются целиком. Но (обычно) операции записи в БД составляют 5-10% от операций чтения. То, что я говорил выше, касается чтения. Запись - тема отдельная.

Если у вас записей 90% от чтений, тогда да, не все сказанное мной будет справедливо.
Я всё ещё не вижу проблемы. Ну, положим, надо вам показать в презентаторе некую сложную сущность, которой нет в БД (т. е. нет и в моей модели) - так эта сущность должна представляться моделью представления. На то view model и существует, чтобы подстраивать модели под нужные представления.

Ну да, вам на показ этой сущности надо сделать несколько запросов в БД. Скажем, если эта сложная сущность состоит из нескольких (не всех) полей трёх сущностей из БД, то сделайте три запроса (если это не связанные сущности). Так вам бы и так пришлось их делать - что в разделённых моделях, что в объединённых. Разве не так?

Кстати, раз надо создавать сущности, не имеющие аналогов в БД, не вижу ничего плохого в том, чтобы одна вью модель имела ссылки на несколько моделей: http://stackoverflow.com/questions/13085670/in-mvvm-is-every-viewmodel-coupled-to-just-one-model .

Я ещё раз говорю, что не вижу криминала. Надо объект модели? - Дергаем запрос в БД через контекст. Получаем что? Правильно - модель с заполненными полями, и с дефолтными значениями для полей, для которых указан атрибут NotMappedAttribute . Теперь берёте значения для таких атрибутов, откуда вам надо, формируете свою составную сущность и показываете в представлении.

Теперь только вопрос, куда поместить этот код, который делает запрос в БД и собирает эту сложную сущность? Если эта сущность зависит от презентатора (у вас это так), то нужно помещать этот код во вью модель, а если от модели предметной области - то эта сущность должна быть в БД, т. е. она должна быть в моей объединённой модели. Проблема решена?



Кстати, я тут даже не упоминаю такие вещи, как репозиторий и прочие лишние нагромождения.

Shocker.ProAlexey2112Ну да, вам на показ этой сущности надо сделать несколько запросов в БД. Скажем, если эта сложная сущность состоит из нескольких (не всех) полей трёх сущностей из БД, то сделайте три запроса (если это не связанные сущности). Так вам бы и так пришлось их делать - что в разделённых моделях, что в объединённых. Разве не так?не пришлось бы, так как одним запросом к БД можно получить несколько сущностей... или некий объект, состоящий из полей из разных сущностей, при этом не притаскивая на клиента ВСЕ поля ВСЕХ задействованных сущностей.

Но это некритично в малонагруженной и не имеющей больших перспектив развития системе.

Alexey2112Я всё ещё не вижу проблемы.Еще раз - для БОЛЬШОГО приложения стоит разделить презентационный слой, слой бизнес-логики и слой БД. Если приложение состоит из нескольких страниц и не имеет больших перспектив разрастаться, то можно использовать ваш подход
А, я понял, что вы имели ввиду. Я выделил это жирным в своём предыдущем посте. Вас беспокоит, что вы получаете не только замапленные поля, но и незамапленные?

Alexey2112Shocker.Proпропущено...
не пришлось бы, так как одним запросом к БД можно получить несколько сущностей... или некий объект, состоящий из полей из разных сущностей, при этом не притаскивая на клиента ВСЕ поля ВСЕХ задействованных сущностей.

Но это некритично в малонагруженной и не имеющей больших перспектив развития системе.

пропущено...
Еще раз - для БОЛЬШОГО приложения стоит разделить презентационный слой, слой бизнес-логики и слой БД. Если приложение состоит из нескольких страниц и не имеет больших перспектив разрастаться, то можно использовать ваш подход
А, я понял, что вы имели ввиду. Я выделил это жирным в своём предыдущем посте. Вас беспокоит, что вы получаете не только замапленные поля, но и незамапленные?
Тогда дайте возможность вью модели собирать такую сущность, которая ей нужна - дайте вью модели ссылку не на модель или модели, а на репозиторий. А то и просто на контекст БД.

Если же вас беспокоит кроссплатформенность - т. е. когда вью модель не может воспользоваться контекстом БД из-за того, что банально на разных языках-фреймворках написаны - то тогда солгасен. Тогда нужны адаптирующие слои (специальный слой репозитория, "модели предметной области", "модели безнес-логики" - как хотите это назовите). Но тогда и говорить надо не о больших и малых приложениях, а о кроссплатформенных и некроссплатформенных.

А что плохого, чтобы на один класс навешать атрибутов из разных понятий? Пусть у одного класса будут атрибуты из DataAnnotations, атрибуты сериализации, атрибуты ещё чего-нибудь. Чтобы не запутаться, можно разделить атрибуты через #region и #endregion.

Shocker.Pro,

а вы скажите, вы считаете, что это нормально, когда при изменении, скажем, столбца в БД, вы должны по цепочке всех слоёв (БД, EF models, repository models, business logic models, serialize models, view models, views) пройтись и поменять это проклятое свойство, учтя "закидоны" каждого из слоёв? Может, стоит облегчить себе жизнь и вместо нескольких "лишних" слоёв добавить атрибутов всего к одному слою?

Alexey2112EF models
Лучше было написать ORM models.

Shocker.ProAlexey2112Вас беспокоитменя ничего не беспокоит ))) я изложил некоторые соображения.

если у вас одна модель на все слои, то получится монолитное приложение. Это не есть плохо во всех без исключения сценариях.

Вы ставите вопрос, что лучше - плодить DTO-модели или перегружать логикой одну единственную модель, от которой зависят все слои. Это вам решать, у каждого подхода свои достоинства, которые, как я вижу, вы прекрасно осознаете )))
Ну да, понятно, что в зависимости от сложности приложения ("большое" приложение в ваших словах), кроссплатформенности и прочих требований одной моделью может и не обойтись.