Я использую Entity Framework 4.1 и ASP.Net MVC 3 для своего приложения. MVC предоставляет уровень представления, промежуточная библиотека предоставляет бизнес-логику, а Entity Framework как бы действует как уровень данных, я полагаю?
Я мог бы разделить код Entity Framework на набор классов репозитория или его соответствующий вариант, что бы ни составляло полезный уровень данных, но у меня возникают проблемы с решением возникшей у меня проблемы дизайна.
Если существует многоуровневый подход, который помогает мне разделять проблемы, тогда очевидно, что мой выбор сохранения данных также не должен быть проблемой для уровня представления. Проблема в том, что, используя Entity Framework, я в основном жестко привязываю свое приложение к понятию, что изменения сущностей отслеживаются и сохраняются автоматически.
Таким образом, скажем, в гипотетическом мире я нашел причину не использовать Entity Framework и хотел заменить ее. Хорошо спроектированное решение должно позволить мне делать это на соответствующем уровне и не затрагивать зависимые уровни, но поскольку весь код пишется с учетом того, что уровень данных отслеживает изменения объекта, я мог бы только заменить Entity Фреймворк для чего-то, что работает аналогичным образом, например nHibernate.
Как мне использовать Entity Framework, но не нужно писать код таким образом, чтобы предполагать, что изменения сущности отслеживаются уровнем данных?
ОБНОВЛЕНИЕ для тех, кто все еще задается вопросом об этой проблеме в своих собственных сценариях:
Айенде Рахиен написала отличную статью, опровергающую весь этот аргумент: http://ayende.com/blog/4567/ложный-миф-об-инкапсуляции-доступа-данных-в-далеке
