Лучшие практики для Entity Framework?

Question

Я пишу новое приложение, используя Entity Framework.

Где будет лежать EF? В настоящее время я думаю о том, чтобы изолировать его в сборке DataAccess, которая предоставляет множество репозиториев (которые по сути обертывают EF).

Затем я создал бы свои собственные доменные объекты и передал бы их в хранилище, которое сопоставляет их с EntityFramework Entity (который я рассматриваю как DAO).

Проблема с этим подходом состоит в том, сколько картографирования мне нужно сделать, даже для модели меньшего домена.

Мне также нравится подход Repository.GetAll(Func<TDomainObj, bool> filter) для получения отфильтрованного числа элементов, однако мне нужно будет преобразовать функцию для получения DAO:

Func<**TDomainObj**, bool> filter --->

Func<**TEntityFrameworkObj**, bool> filter

Не уверен, как я мог это сделать? Если бы я просто разрешил Func<TEntityFrameworkObj, bool> в хранилище, вызывающая сторона должна была бы знать о System.Data.Objects.

Я начинаю думать, что мне нужно просто соединить приложение с EF и использовать их System.Data.Objects в качестве моей модели ....

Ждем ваших предложений / комментариев,

David

Answer 1

Джули Лерман предлагает бесплатную онлайн-презентацию советов и приемов EF завтра .

Я буду представлять " Как мыслить как Entity Framework (и почему вы, возможно, захотите это делать в первую очередь) * " на бесплатной онлайн-конференции CodeRage в сентябре . Презентация будет доступна для скачивания в ближайшее время.

Answer 2

Мы инкапсулируем EF за сервисным уровнем. Уровень обслуживания предоставляет объекты DTO. Мы сопоставляем объекты EF объектам DTO в коде.

В некоторых случаях мы делаем шаблон get by, который похож на то, что вы делаете. Куда мы отправляем объект, например клиента, и возвращаем всех клиентов, похожих на того, которого мы отправили