Entity Framework, прикладные уровни и разделение задач

Question

Я использую Entity Framework 4.1 и ASP.Net MVC 3 для своего приложения. MVC обеспечивает уровень представления, промежуточная библиотека обеспечивает бизнес-логику, а Entity Framework действует как уровень данных, я полагаю?

Я мог бы разделить код Entity Framework на набор классов репозитория или их соответствующий вариант, независимо от того, что представляет собой полезный слой данных, но у меня возникли проблемы с решением проблемы проектирования, которая у меня есть.

Если существует многоуровневый подход, помогающий мне разделять проблемы, то вполне естественно, что мой выбор постоянства данных также не должен затрагивать уровень представления. Проблема в том, что, используя Entity Framework, я в основном тесно связываю свое приложение с понятием, что изменения сущностей отслеживаются и сохраняются автоматически.

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

Как мне использовать Entity Framework, но мне не нужно писать мой код таким образом, чтобы предполагать, что изменения сущностей отслеживаются слоем данных?

ОБНОВЛЕНИЕ для тех, кто все еще интересуется этой проблемой в своих собственных сценариях:
Ayende Rahien написала отличную статью, снимая весь этот аргумент: http://ayende.com/blog/4567/the-false-myth-of-encapsulating-data-access-in-the-dal

Answer 1

Если вы хотите продолжать в том же духе, вам следует бросить программирование и изучать философию.Структура сущностей - это абстракция постоянства, и существует правило Leaky abstraction , которое гласит, что любая нетривиальная абстракция в некоторой степени является утечкой.подготовиться к гипотетическим ситуациям.Большую часть времени это просто позолота .Каждое изменение имеет свою стоимость.Изменение уровня персистентности позже в проекте является дорогостоящим, но это также очень редко.С точки зрения клиента, нет причин оплачивать часть этих затрат в большинстве проектов, где это изменение не требуется.Если мы глубже обсудим точку зрения клиента, мы можем сказать, что он вообще не должен за это платить, потому что выбор плохого API, который должен быть заменен позже, является провалом разработчиков / архитекторов.Рефакторинг вашего кода регулярно, но только до такой степени, которая необходима для добавления новых функций, которые нужны клиенту, иначе вы вряд ли сможете быть конкурентоспособными на рынке.Это, конечно, имеет некоторые исключения:

• Заказчик хочет (или архитектура требует этого по любой причине, и клиент соглашается с этим) такой абстракции.В таком случае вы должны посчитать это и определить архитектуру, открытую для таких изменений.
• Это хобби или проект с открытым исходным кодом, где вы можете делать то, что хотите, потому что он не ограничен некоторыми ресурсами

Теперь к вашей проблеме.Если вам нужна такая высокоуровневая абстракция, вы не должны выставлять сущности своему контроллеру.Предоставьте DTO из бизнес-уровня (или даже из репозиториев) и добавьте такие поля, как IsNew, IsModified, IsDeleted, в эти DTO.Теперь ваш пользовательский интерфейс полностью отделен от персистентности, но ваша архитектура намного сложнее, и, вероятно, нет причин для такой сложности - она ​​чрезмерно спроектирована.Другим способом может быть простое отключение отслеживания (добавьте AsNoTracking() к каждому запросу) и создание прокси на ваших сущностях (context.Configuration.ProxyCreationEnabled) - отложенная загрузка также не будет работать.Это все равно, что отбросить большинство функций персистентности.

Есть и другие точки зрения.Я рекомендую вам прочитать недавние посты Айенде о репозитории и его комментарии к архитектуре Sharp.

Answer 2

Краткий ответ?Вы неВы можете отключить отслеживание EF, а затем не беспокоиться об этом, но это все.

Если вы собираетесь написать свой презентационный слой с ожиданием, что изменения отслеживаются и сохраняются автоматически, тогда все, что вы заменитеEF с должен сделать это.Вы не можете заменить это на что-то, что не отслеживает и не сохраняет изменения автоматически и просто ожидает, что что-то продолжит работать.Это все равно, что взять систему, которая использует дуплексную связь по TCP / IP-соединению, заменить ее на HTTP-соединение (которое по природе HTTP не является дуплексным) и ожидать, что все будет работать так же.Это не так.

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

Это выполнимо, но это будет очень много работы для проблемы, которая на самом деле очень редко случается.Это также собирается добавить дополнительную сложность проекту.Ладислав грохнулся: абстрагироваться не стоит.

Answer 3

Пожалуйста, прочитав проект Microsoft n-layer, прочитайте блог ayenede. Г-н Айенде опубликовал серию сообщений о преимуществах и недостатках проекта Microsoft n-layer.

Answer 4

Вам следует реализовать шаблон репозитория и обычный POCOS, если вы беспокоитесь о возможной замене EF.

На Codeplex есть отличный проект, который занимается дизайном, управляемым доменом, включая документацию. Взгляните на это.

http://microsoftnlayerapp.codeplex.com/