Что такое правильная абстракция с использованием Entity Framework в веб-формах

Question

Я пытаюсь найти хороший способ для разработки моего решения.Я знаю, что буду использовать следующие технологии, Asp.Net Webforms и Entity Framework 4.1.Моя модель EF основана на существующей базе данных.Я планирую использовать генератор EF DbContext для построения моего контекста и сущностей.И это тот момент, когда все становится немного сложнее для меня.

Я хочу иметь правильное разделение задач, обеспечивая лучшую тестируемость и позволяя мне отделить свою бизнес-логику от моего DAL.У меня есть три проекта в моем решении в настоящее время: Web, Core и Data.Я хотел бы, чтобы зависимости были Web -> Core <- Data, без какой-либо зависимости между Web и Data.Это требует, чтобы мои сущности действительно существовали в Core, а не в Data (где мой edmx).В настоящее время моя мысль состоит в том, чтобы переместить файл Entities.tt в Core и изменить inputFile так, чтобы он указывал на мой edmx в Data для генерации моих Entities в Core.Но я не уверен, что делать с контекстом.Это сильно зависит от EF, и поэтому я не просто хочу перенести это в Core.Я подумал об интерфейсе, создании собственного IEntities.Context.tt и отбрасывании его в Core.Меня беспокоит потеря функциональности, если мой интерфейс не создает DbSets и DbContext. </p>

Две мысли, которые у меня были по этому поводу: 1) поставить ссылку на System.Data.Entity в Core, 2) не используйте DbSet и не заменяйте его на ICollection (или некоторый такой универсальный контейнер) и оборачивайте DbContext как просто объект в моем интерфейсе.

Любое понимание будет очень приветствоваться.Спасибо.

Answer 1

Если ваше решение полностью ориентировано на будущее, тогда мне нравится использовать подход, основанный на коде, в рамках сущности (простите за бесстыдный плагин, но я разместил в своем блоге учебник об этом http://www.terric.co.uk/code-first-entity-framework-and-sql-migrations/). Мне нравится управление, которое оно дает мне, что я не могу получить, когда я генерирую .edmx.

Переходя к структуре, я обычно разделяю слои своего проекта на отдельные сборки: домен (и данные) и веб-интерфейс, структурированный со следующими папками (пространствами имен):

Domain (business layer and data layer assembly)
    Data (contains my EF data context and Interface to the context)
    Entities (contains my POCO objects for the context)

WebUI (presentation layer assembly)
    Infrastructure (contains my dependency inject initialiser)

Я никогда не DI мои сущности и вместо этого использую бетоны в моем уровне представления, однако контекст, который я всегда буду DI, как я могу / должен использовать ADO.Net (особенно для устаревших приложений), где мой уровень домена будет по-прежнему использовать ADO.Net для чтения / записи моих объектов POCO. Таким образом, когда я в конечном итоге получаю возможность внедрить ORM с помощью своего старого приложения, я могу просто добавить версию ORM в свой домен.

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

Answer 2

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

1) Добавьте бизнес / сервисный уровень - это будет абстрагироваться между вашим уровнем данных и вашим уровнем презентации. Это наиболее часто используемый мной подход - использование AutoMapper и Dependency Injection (мне нравится Ninject), чтобы облегчить работу обезьяны. Ваш бизнес-уровень будет представлять либо собственную версию объектов вашей базы данных (не рекомендуется), либо объекты, связанные с вашей бизнес-моделью (более надежный подход).

2) Используйте шаблон Inversion of Control - очень популярный в данный момент, хотя я пока не собираюсь его использовать в реальной жизни. Очевидно, это очень хорошо для TDD / mocking и т. Д. ... это в основном означает, что ваш уровень данных зависит от вашего бизнес-уровня, а не наоборот.

К вашему сведению - мои «базовые» или «общие» сборки ничего не знают о моем бизнесе или слоях данных - они просто предоставляют независимые от платформы помощники и общие классы - например, если я хочу создать общую функциональность MVC, я создам Company.MVC.Core сборка вместо.