Ответ 1
http://ayende.com/Blog/archive/2007/06/08/Rhino-Commons-RepositoryltTgt-and-Unit-Of-Work.aspx
Посмотрите на приведенный выше пример, вы можете реализовать структуру сущности тем же способом, используя шаблон репозитория
Использование Entity Framework в качестве уровня доступа к данным
В моем приложении ASP.NET я хочу реализовать слой данных acess, используя Entity framweok, поэтому я могу использовать его как инструмент ORM. Но я не хочу, чтобы остальная часть приложения заботилась о том, чтобы я использовал это или был загрязнен каким-либо конкретным объектно-ориентированным элементом.
Кажется, я нахожу любого, кто использует структуру сущности исключительно на своем уровне доступа к данным, поэтому я заинтересован в том, чтобы увидеть какие-либо онлайн-примеры этого/опыта у людей.
Ответы
Ответ 2
Вы можете абстрагировать инфраструктуру сущности, используя что-то вроде шаблона репозитория, например, ScottGu с Linq в серии NerdDinner.
Ответ 3
это DDD-вдохновленная архитектура, я только что работал с EF v4, который использует Unity IoC для ввода репозитория EF, надеюсь, что он поможет
Ответ 4
Я использовал Entity Framework в качестве доступа к данным в моих последних двух проектах. Это большие (для меня по крайней мере) проекты с несколькими сотнями таблиц, 5-15 разработчиков, которые продолжаются в течение года.
В обоих проектах у нас есть интерфейс WCF на наш сервисный уровень. Мы не хотели использовать объекты Entity Framework в наших контрактах WCF. Поэтому мы создали Data Transfer Objects, и мы сопоставляем между объектами DTO и Entity Framework.
Это разлагает зависимости и сохраняет контракты как можно более стабильными, но создает дополнительную работу.
В зависимости от вашего временного горизонта я бы сделал это так или использовал объекты POCO в следующей версии, как упоминал Кети.
Ответ 5
EF или любой другой ORM (то есть NHibernate) не заменяет ваш уровень доступа к данным. Скорее, ORM - это уровень абстракции от DAL к источнику данных.
Не обманывайтесь, полагая, что EF справляется с DAL. EF - это еще одна структура данных. Однако в наилучшей практике вы все же хотите абстрагироваться и централизовать весь доступ (чтение/запись) в общем DAL.
Вот прекрасный пример того, что я говорю. Предположим, что вы должны удалить данного пользователя в одном из ваших вариантов использования. Однако при удалении пользователя вы можете удалить другие записи, связанные с удаленным пользователем, чтобы избежать сиротских записей (честно говоря, я бы использовал для этого хранимую процедуру). Теперь этот прецедент застрял в какой-то БО, которая очень специфична для этого случая использования и удаляется, поскольку пользователь является лишь одной частью общего варианта использования.
В какой-то момент у вас есть разработчик, которому предлагается включить другой вариант использования, который, как ожидается, приведет к удалению пользователя! Разработчик может сделать несколько вещей. 1) Он может создать новый прецедент, который теперь включает удаление пользователя, но забыл удалить любые связанные записи этому пользователю. 2) Возможно, он заметил предыдущий случай использования, но не мог использовать его напрямую, не обобщая его для своего варианта использования, поэтому он решил скопировать часть этого варианта использования, которая надлежащим образом удалит пользователя и связанные с ним записи, в его прецедент, Теперь у нас есть дубликаты частей кода, которые делают практически одно и то же - удалите пользователя. Юк! Теперь, добавив этот "удаляющий пользователя" в класс помощника DAL.Users, вы избегаете этой плохой проектной практики.
В любом случае, одна хорошая вещь об EF, это уменьшает количество бизнес-объектов, которые я использовал для создания вручную, и предоставляет другое представление данных с уровня приложения, чем то, что видно на уровне хранилища данных.