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

Question

Шаблон репозитория используется для абстрагирования от конкретной используемой базы данных и технологии отображения объектных отношений (например, EF). Так что в будущем я могу легко заменить (например) мои отображения структуры Entity на Linq на SQL, если я решу это сделать.

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

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

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

Также обратите внимание, что я использую EF прежде всего из-за его способности генерировать все из этой визуальной диаграммы - я просто проектирую диаграмму и позволяю ей генерировать базу данных для меня со всеми внешними ключами и т. Д. Мне это очень нравится и не нравится хочу даже подумать о командах SQL.

Answer 1

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

Представление репозиториев добавит новый уровеньсложность.У репозиториев есть свои плюсы и минусы.Представляем их только потому, что «вы можете изменить подход к доступу к данным в будущем» - плохая причина.Не разрабатывайте свое приложение, потому что что-то может произойти.Разработайте приложение на основе текущих реальных требований (гибким способом) и проведите рефакторинг вашего кода, если необходимо внести изменения - это единственный способ быть конкурентоспособным на рынке.Функции продают ваше ПО, а не его открытую архитектуру для каких-либо изменений (хорошо, есть исключения, но в таких случаях открытая архитектура является требованием высшего уровня).

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

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

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

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

• Генератор ADO.NET DbContext против генератора объектов ADO.NET POCO
• Только код EF POCO VS EF POCO с объектомМодель данных

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

Answer 2

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

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

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

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

Answer 3

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

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

• ADO.NET EntityObject Generator
• ADO.NET POCO Entity Generator
• ADO.NET Автономный генератор сущностей

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

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

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

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

1. Установить EF4.1
2. Создайте свою модель (используя подход Модель-сначала)
3. Создайте базу данных из вашей модели
4. Создайте свои классы сущностей с помощью DbContext Generator

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

Answer 4

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

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