Шаблон репозитория с инфраструктурой Entity

Ответ 1

Репозиторий всегда зависит от технологии доступа к данным. Это причина, по которой люди используют репозитории - обернуть зависимость доступа к данным отдельному слою. Если вы решите изменить технологию доступа к данным (imho это похоже на 1% вероятность того, что вы это сделаете), вам придется создавать новые репозитории, реализующие те же интерфейсы, что и прежние.

Введение repositoris добавит новый уровень сложности. У репозиториев есть свои плюсы и минусы. Представляя их только потому, что "вы можете изменить подход к доступу к данным в будущем", является плохой причиной. Не разрабатывайте приложение, потому что что-то может случиться. Создайте приложение, основанное на текущих реальных требованиях (гибкий способ) и реорганизуйте свой код, если потребуется изменение - это единственный способ быть конкурентоспособным на рынке. Функции продают ваш SW, а не его открытую архитектуру для любого типа изменений (хорошо, есть исключения, но в таких случаях, когда открытая архитектура является требованием верхнего уровня).

При использовании EF у вас есть несколько вариантов создания сущностей:

• Используйте инструмент cutom для создания объектов Entity. Это подход по умолчанию, который создает файл "code behind" для EDMX. Это единственное доступное решение в EFv1 (.NET 3.5 SP1).
• Используйте шаблоны T4 для создания объектов Entity, POCOs, STE или любых настраиваемых типов сущностей (вы можете модифицировать логику генерации). Это часто используется с EFv4.
• Пишите POCO сами. Это можно использовать с EFv4, и он всегда используется с первым подходом кода в EF 4.1.

Если вы ожидаете, что технология доступа к данным может измениться в будущем, используйте либо второй, либо третий подход с POCOs. В случае шаблонов T4 вы можете просто скопировать сгенерированные POCO или изменить файл проекта, чтобы вы не потеряли их после удаления EDMX файла.

Если вы не уверены, подходит ли второй или третий подход, вы можете проверить мои ответы на следующие вопросы:

• ADO.NET Генератор DbContext и Генератор объектов ADO.NET POCO
• Код EF POCO только VS EF POCO с моделью данных сущности

Поскольку я как-то согласен с ответом @Patko, вы также должны проверить блог Айенде. Он написал несколько сообщений об использовании репозитория и над приложениями для архивирования. Он пишет о NHibernate, но аналогичные решения могут быть сделаны с EF. Единственное отличие состоит в том, что NHibernate предлагает лучшую абстракцию, поэтому лучше использовать тестовый код с использованием NHibernate.

Ответ 2

Возможность переключиться с одной технологии настойчивости на другую - это хорошо и все, но вам она действительно нужна?

Прежде всего, что такое репозиторий? По определению Fowler он предоставляет доступ к объектам в виде коллекции, подобный памяти. Но каждый современный инструмент ORM уже делает это, поэтому еще один уровень абстракции просто добавляет немного сложнее.

Во-вторых, переход от одной технологии персистентности к другой обычно более сложный, чем просто предоставление другой реализации репозитория. Например, как вы собираетесь обрабатывать транзакции? Транзакции обычно зависят от контекста и обрабатываются за пределами репозиториев. Разумеется, вы можете использовать какую-то единицу работы, но тогда вам нужно будет внедрить новую единицу работы для каждой технологии персистентности.

Я не хочу сказать, что вы не должны использовать репозитории, просто, возможно, подумайте.

Ответ 3

Сущности классов, созданных дизайнером EF, находятся в вашем проекте внутри вашего "Model.Designer.cs". Вы можете скопировать код, чтобы ваши объекты оставались в вашем проекте, даже если вы удалите свою модель или ссылки из EF. Тем не менее, они тесно связаны с EF, поэтому вы должны стремиться к развязыванию EF из классов сущностей.

До сих пор у вас были шаблоны T4, которые могли бы помочь вам в развязывании, но они все равно потребуют некоторых изменений в выбранном T4:

• Генератор EntityObject ADO.NET
• Генератор объектов ADO.NET POCO
• ADO.NET Self-Tracking Entity Generator

EF4.1 предоставляет упрощенный API, DbContext, что улучшает ваш опыт работы с EF, когда вы хотите разделить классы сущностей. С EF4.1 вы получаете 3 подхода:

• Первый код
  • вы создаете классы, а EF создает БД, как это должно быть
  • классы не исчезнут при удалении ссылок на EF
  • у вас не будет конструктора
• База данных сначала
  • Если у вас уже есть база данных, модель будет создана для вас на дизайнере
  • вы можете создавать классы сущностей с помощью нового шаблона T4. Генератор DbContext
• Первая модель
  • как вы уже делаете прямо сейчас, вы создаете свою модель в дизайнере
  • вы можете создавать классы сущностей с помощью генератора DbContext

Теперь, отвечая на ваш вопрос:

Как удалить эту зависимость?

• Установить EF4.1
• Создайте свою модель (используя подход, основанный на модели)
• Создайте свою базу данных из своей модели.
• Создание классов сущностей с помощью генератора DbContext

Посмотрите, как вы можете сделать все это здесь: EF 4.1. Модель и база данных для первого прохода.
Вы должны прочитать серию в блоге команды ADO.NET Использование DbContext в функции EF CTP5 Часть 1: Введение и модель (ранее был известен EF4.1 как функция EF CTP5).
Вы можете получить более подробную информацию в моем вопросе: EF POCO код только VS EF POCO с моделью данных сущности.

Ответ 4

Одной из новых возможностей в Entity Framework версии 4 является разработка "Code First". Это позволит вам использовать обычные классы С# (POCO) с инфраструктурой сущностей. Как только ваши классы написаны таким образом, вы можете написать другую реализацию репозитория, который сохраняет эти классы с использованием другого механизма.

У ScottGu есть сообщение в блоге, содержащее дополнительную информацию.