Есть такая две таблицы Persons и Categories, отношение один ко многим. Генерируем сущности через EF4, как поступить по правилам MVVM? пока рассматриваю два варианта, но может ни один из них не правильный

1.    Сущности, созданные с помощью EF4,  считаю моделью. В модели представления работаю с этими сущностями.
2.     Модель – это класс, полями которого являются сущности EF4. А в модели представления работаю непосредственно с моделью.
Второй вариант получается более громоздким, но как мне кажется, более правильным и легче тестируемым. Может я ещё какие то моменты упускаю?

Некоторые люди предлагают работу с БД через EF вынести в WCF. Это нормальная практика? Решение состоит из нескольких проектов, основное приложение WPF, не будет ли извратом сюда ещё WCF пихать?

Я бы считал сущности EF моделями, и использовал бы их внутри моделей представлений. Условно:


Как ты будешь доступаться из представления - это вопрос открытый. Я предпочитаю доступаться к detached копии модели. Копировать данные в саму модель представления не комильфо, потому что часто валидация модели (IDataErrorInfo) осуществляется в самом классе модели.

Тех, кто советует пользоваться WCF лучше не слушай. Если тебе он не нужен, значит и не используй его. Он только усложнит общую структуру, а плюшек особых не добавит. То есть суть одна - если тебе нужен сервис, то пользуй WCF, а если нет - то не пользуй 

Kefir, в том то и дело, что он мне не нужен.

Но вот не удаётся создать контекст из другой сборки. То есть, есть например App.exe и Add.Data.dll. Естественно ссылка на Add.Data.dll в App.exe есть  . В Add.Data.dll сущности EF и всё что надо для соединения с БД, а вот контекст в App.exe создать не получается. Оно то и понятно, ведь при создании контекста, EF пытается найти необходимые данные в главной сборке, в то время как они находятся в Add.Data.dll. Как это обойти?

а у меня была задача 3-х звенка классическая: база--сервер--клиент.
С базой я общался по EF, далее на wcf сервисе работал с Repository, который отдавал уже DTO сущности (автогенератор+AutoMapper) (попросту говоря я конвертировал EF->DTO)

Самое интересное начиналось на клиенте. В DTO были ссылки на справочники, которые я кешировал на клиенте используя пример ADO.NET Sync Framework via WCF Serivice. Так вот, для каждого презентатора (я использовал классическую модель MVP) у меня генерировались (автоматом) Декораторы (которые были на самом деле прокси - то есть содержали в себе полную сигнатуру) DTO объектов, в которые я добавлял нужные мне property.
Например: мне надо было сделать таблицу с чекбоксами на основе DTO полученных данных, с раскрытием ссылок на справочники (в DTO передавались id из исправочников) -  я просто добавлял bool IsChecked {get;set;} + справочный_элемент Some {get {return cache.getById(wrappedObject.справочный_элемент_id;}}.
Кроме того, т.к. генератор генерировал мне для каждого презентера свои декораторы (чтобы они не пересекались) я добавил генерацию различных partial методов (типа "beforeSetProperty\AfterSetProperty")...


Пока полёт нормальный....

Это сообщение отредактировал(а) jonie - 2.8.2011, 08:11

Rohoss, я не понял почему ты не можешь создать контекст в App.exe. В чем проблема?

Добавлено через 1 минуту и 19 секунд
jonie, у тебя сервер есть, а если человеку он не нужен, то зачем впутывать WCF? По-моему, это только добавит проблем.

Получаю такое исключение


Проект прикрепил к сообщения. Модель на основе AdventureWorks



Присоединённый файл ( Кол-во скачиваний: 8 )
 WpfTestEF.zip 123,52 Kb

Собственно и с WCF похожие проблемы. Допустим, есть три проекта: сам WCF, пользовательское приложение, и библиотека, которая будет работать с WCF и использоваться главным приложением. Однако, сущности полученные с WCF не удаётся передать в основное приложения.
Тестовый проект тоже сделал и прикрепил   


Присоединённый файл ( Кол-во скачиваний: 7 )
 WpfApplication5.zip 192,78 Kb

Rohoss, в проекте, где у тебя сделан EF открой config файл - там увидишь конфиг самого соединения для EF. Скопируй этот кусок конфига в проект с App.exe и всё должно заработать. Фишка в том, что EF просто не понимает где взять connection string.

Я тоже так думал, но не заработало. Причина, скорее всего, в том, что нужна не только строка соединения а и сам файл модели данных. А он находится в ресурсах сборки-библиотеки. Вопрос решить конечно можно, но с такими решениями не захочется ничего в отдельные сборки выносить   

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

Rohoss, значит ты перемудрил. У всего мира так работает (в том числе и у меня), а у него не работает 

Kefir, только что проверил, действительно перемудрил. на тестовом проекте работает.

Всё, тему считаю закрытой