Использование Entity Framework в качестве уровня доступа к данным

Question

В моем приложении ASP.NET я хочу реализовать слой доступа к данным, используя Entity framweok, чтобы я мог использовать его в качестве инструмента ORM. Но я не хочу, чтобы остальная часть приложения заботилась о том, что я использую это или что-то связано с какой-либо конкретной структурой объекта.

Кажется, я не могу найти кого-либо, кто использует платформу сущностей исключительно в своем слое доступа к данным, поэтому мне бы хотелось увидеть любые онлайн-примеры этого / опыта, которые есть у людей.

Answer 1

Вы можете абстрагировать структуру сущностей, используя что-то вроде шаблона хранилища, как это делает ScottGu с Linq в серии NerdDinner.

http://nerddinnerbook.s3.amazonaws.com/Part3.htm

Answer 2

http://ayende.com/Blog/archive/2007/06/08/Rhino-Commons-RepositoryltTgt-and-Unit-Of-Work.aspx

Посмотрите на приведенный выше пример, вы можете реализовать структуру сущностей таким же образом, используя шаблон репозитория

Answer 3

http://blog.keithpatton.com/2009/05/30/Entity+Framework+POCO+Repository+Using+Visual+Studio+2010+Net+40+Beta+1.aspx

это архитектура, основанная на DDD, я только что работал с EF v4, которая использует Unity IoC для внедрения хранилища EF, надеюсь, это поможет

Answer 4

EF или любой другой ORM (т.е. NHibernate) не заменяет ваш уровень доступа к данным. Скорее ORM - это уровень абстракции от DAL до источника данных.

Не обманывайте себя, полагая, что EF покончил с DAL. EF - это просто еще одна структура источника данных. Тем не менее, в лучшем случае вы все еще хотите абстрагировать и централизовать весь доступ (чтение / запись) в общем DAL.

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

В какой-то момент времени у вас есть разработчик, которого просят включить другой вариант использования, который случается вовлекать, удаляя пользователя! Разработчик может сделать несколько вещей. 1) Он может создать новый сценарий использования, который теперь включает удаление пользователя, но забыл удалить все связанные с ним записи этого пользователя. 2) Он, возможно, заметил предыдущий вариант использования, но не мог использовать его напрямую, не слишком обобщив его для своего варианта использования, поэтому он решил скопировать часть этого варианта использования, которая должным образом удаляет пользователя и связанные с ним записи, в его сценарий использования , Теперь у нас есть дубликаты частей кода, которые делают практически то же самое - удаляют пользователя. Юк! Теперь, поместив этого «удаляющего пользователя» в, скажем, вспомогательный класс DAL.Users, вы избежите этой плохой практики проектирования.

В любом случае, одна из приятных особенностей EF - это уменьшение количества бизнес-объектов, которые я использовал для создания вручную, и представление данных на уровне приложений, отличное от того, что видно на уровне хранилища данных.

Answer 5

Я использовал Entity Framework в качестве доступа к данным в моих последних двух проектах. Это большие (по крайней мере, для меня) проекты с несколькими сотнями таблиц, 5-15 разработчиков продолжительностью более года.

В обоих проектах у нас есть интерфейс WCF на нашем сервисном уровне. Мы не хотели использовать объекты Entity Framework в наших контрактах WCF. Поэтому мы создали объекты передачи данных и сопоставляем объекты DTO и Entity Framework.

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

В зависимости от вашего временного горизонта, я бы сделал это так или использовал бы объекты POCO в следующей версии, как упоминал Киет.