Есть ли причина использовать шаблон репозитория с Entity Framework, если я знаю, что когда-либо буду использовать EF?

Из чтения различных книг и статей я, скорее всего, часто нахожу использование предложенного шаблона репозитория. Я понимаю, что если вам нужно поменять свой уровень данных от одного к другому, но мой вопрос заключается в том, что если я знаю со 100% уверенностью, что я не буду использовать какие-либо другие технологии для доступа к данным, есть ли какая-либо причина для используя указанный шаблон?

То, что я больше всего сомневаюсь в том, что я действительно не вижу, что этот дополнительный слой абстракции может привести к таблице в этом сценарии. По моему опыту, EF с его плавными функциональными возможностями linq-to-entities должен быть более чем достаточно для удовлетворения всех моих потребностей.

Наиболее обычными случаями, по-видимому, являются запуск репозиториев с помощью таких методов, как FindAll, Find, Add и Delete, все из которых легко доступны непосредственно через EF (поэтому не нужно дублировать код).

Я просто пропустил какую-то большую точку или больше хранилище, когда вам нужно поддерживать несколько разных технологий доступа к данным?

Ответ 1

У них много мнений по этой проблеме, но после использования репозиториев для 2 проектов я больше никогда не пробовал.

Слишком много боли с сотнями методов для всех этих случаев без явных преимуществ (я почти никогда не собираюсь менять EF для другого ORM).

Лучшим советом будет опробовать его, чтобы вы могли сделать информированное мнение о том, какой маршрут принять.

Некоторые мнения против него здесь

Ответ 2

Я думаю, что ты в правильном направлении. Я задал себе тот же вопрос два года назад после того, как я использовал шаблон репозитория в некоторых проектах. Я пришел к выводу, что спрятать ORM за репозиторием, реализованным поверх вашего ORM, вы получите не что иное, как ненужную работу. В дополнение к реализации бессмысленных методов FindAll, Find, Add... вы можете потерять некоторые возможности оптимизации производительности, которые предоставляет ORM. Или, по крайней мере, будет довольно сложно применить некоторые из этих методов.

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

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

Ответ 3

Я не так горяч по шаблону репозитория, каким я был раньше, но все же считаю, что он может быть полезен в следующих сценариях (предполагая, что замена ORM не является одним из них):

Тестирование модулей (предполагая, что вы скорее издеваетесь или заглушаете, чем используете Sqlite или попадете в реальный db)
Возможность заглушить доступ к данным во время разработки через репозиторий, который имеет встроенный в память IEnumerable в качестве источника поддержки.

Ответ 4

То, что люди не понимают, это то, что EF уже является репозиторием и подразделением.

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

Создайте репозиторий и подразделение работы поверх EF, если ваше приложение

очень большой (слой лазаньи)
долгоживущий (10 лет или около того)
работает более 5 разработчиков, работающих параллельно.
есть разработчики, отделенные географически
требует много обслуживания
несколько инфраструктур доступа к данным

Хорошим показателем является то, что при обновлении с EF5 до EF6 вам нужно стучать в дверь.

Ответ 5

Я действительно не согласен с тем, что EF является правильным примером "шаблона хранилища". Это типизированный уровень доступа к данным и открытая реализация LINQ.

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

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

Это соглашение о том, как Microsoft определяет "Шаблон хранилища" - обратите внимание, что бизнес-объекты отображаются в источник данных. (И, таким образом, мое фундаментальное несогласие с EF, выполняющим эту роль: EF имеет шанс только на разумные карты бизнес-объектов, когда они разработаны с первого кода.)

Лучшее суммирование/статья, которую я нашел, Шаблон репозитория, сделанный справа от Gauffin. Хотя он подходит к шаблону репозитория с более экстремальным представлением, чем я, вот несколько ключевых моментов относительно того, почему EF просто истекает кровью через шаблон Active Record/ORM.

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

Шаблон репозитория - это абстракция. Его цель - уменьшить сложность и сделать остальную часть кода ненадежной. В качестве бонуса вы можете писать модульные тесты вместо тестов интеграции. Проблема в том, что многие разработчики не понимают цели шаблонов - и создают репозитории [т.е. EF], которые утечки сохраняют определенную информацию до вызывающего абонента

..

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

..

Когда люди говорят о шаблоне репозитория и модульных тестах, они не говорят, что шаблон позволяет использовать модульные тесты для уровня доступа к данным. Если вы используете ORM/LINQ в своей бизнес-логике, вы никогда не можете быть уверены, почему тесты потерпеть неудачу.

..

Обратите внимание, что шаблон репозитория полезен только в том случае, если у вас есть POCOs, которые сначала отображаются в коде. В противном случае вы просто разделите абстракцию с помощью сущностей. [То есть, только EF Code First может даже попытаться выполнить это требование.]

..

Создание правильной реализации репозитория очень просто. Фактически, вы должны следовать только одному правилу: не добавляйте ничего в класс репозитория до самого момента, когда вам это нужно

И если вы используете EF в качестве репозитория - я считаю, что он все еще типизировал DAL, насколько он кровоточит - пожалуйста, не пытайтесь скрыть его в "более общем" шаблоне - шаблон хранилища не связан с унификацией типов, речь идет об экспонировании совокупных корней для конкретного контекста и операций над такими.

См. Какая конкретная проблема решает проблему шаблона репозитория?.

Пока я просматриваю EF как правильный шаблон репозитория - это шаблон Active Record - я не пурист репозитория. То есть бывают случаи, когда я удалю объекты EF (или L2S) в конкретных случаях; Я принимаю это как технический долг. Просто ознакомьтесь со стоимостью взлома такой границы репозитория/домена.