Как EF влияет на дизайн ASP.NET приложений

Если создавая ASP.Net приложение, вы сумели оторваться от дизайнера ASP.NET страниц, и уже не складываете на странице датасеты, и объекты соединения с БД, значит вы пошли по пути структуризации дизайна вашего web приложения. Наверняка вы выделили классы или модули (сборки) для чтения записи данных в БД, и отдельные классы для представления этих данных и размещения бизнес логики. Возможно вы пошли дальше, и в слое представления выделили логические классы контроллеры, в которые поместили логику организации последовательности действий (workflow), создания представления и валидации пользовательского ввода, оставив в aspx ascx файлах только разметку. А может вы не стали этого делать и функции контроллера оставили в aspx формах.

Как повлияет на сложившуюся архитектуру ваших ASP.NET приложений использование Entity Framework? Хорошая новость состоит в том, что EF наверняка легко впишется в ваше приложение при использовании любого дизайна (даже если вы дружите с дизайнером ASP.NET страниц :).

Однако EF незатейливо подталкивает нас к использованию "анемичной модели", когда классы домена (данные) отдельно, а бизнес-операции (сервисы) отдельно. И это достаточно удобная организация кода.

В качестве классов домена используем сущности EF. Запихивать бизнес логику в partial классы EF я бы не советовал. На этот счет есть много резонов, главные из них:
- вы увеличиваете зависимости между сущностями.
- часто это нарушает принцип single responsibility
- структуры данных меняются чаще чем бизнес правила и объединив то и другое в одном классе вы получите проблемы при внесении изменений.
В partial классы для сущностей EF полезно помещать всякие хитрые свойства (вычисляемые, виртуальные и т.д.), а также логику пре- и пост-валидации значений персистентных свойств (это делается при помощи partial methods, генеримых дизайнером EF).

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

Какой вариант выбрать - вам решать. Однако,если вы создаете полноценный Service layer - то ObjectConext не должен болтаться в параметрах бизнес-методов. Использование ObjectConext на уровне контроллера в слое представления позволяет более тонко гранулировать бизнес логику и получить за счет этого более эффективное решение (т.е. вместо "больших" бизнес-методов, которые сосредоточенно что-то там делают внутри, вы имеете много "маленьких" бизнес методов, которые получают на вход контекст и вы можете комбинировать их, выстраивая нужную логику). Эффективность может увеличиться в числе прочего, за счет того, что время жизни ObjectConext будет больше, и следовательно, больше возможностей воспользоваться преимуществами кэширования объектов. Важно понимать, что в этом случае вы платите за повышение эффективности большей связностью между уровнями бизнес логики и представления, и вам, в первую очередь, будет сложнее вносить изменения в существующее решение.

Не следует опасаться создавать экземпляры ObjectConext, не следует пытаться создать для хранения контекста каки либо потоковые переменные и, тем более, синглтоны. Дело в том что EF достаточно эффективно кэширует на уровне домена приложения (Application Domain) внутри себя всю метаинформацию, и после создания первого экземпляра ObjectConext, последующие создаются достаточно быстро. Кроме того, ObjectConext не является потокобезопасным, поэтому не следует пытаться использовать глобальный ObjectConext на уровне приложения или сессии.

Следует избегать ситуаций, когда у вас создаются параллельно несколько ObjectConext в одном потоке, а также создания вложенных ObjectConext. Это может приводить к коллизиям при обновлении и сохранении данных.