Универсальный репозиторий с EF 4.1 в чем смысл

Question

Универсальный репозиторий с EF 4.1 в чем смысл

когда я углубляюсь в DbContext, DbSet и связанные с ними интерфейсы, мне интересно, почему вам нужно будет реализовать отдельный "общий" репозиторий вокруг этих реализаций?

похоже, что DbContext и IDbSet делают все, что вам нужно, и включают "единицу работы" внутри DbContext.

Я что-то упускаю здесь или кажется, что людям нравится добавлять еще один уровень зависимости без причины.

466 3

repository-pattern entity-framework-4.1 unit-of-work

3 ответов:

Comments

Ничего не найдено.

Ladislav Mrnka · Accepted Answer · 2017-05-23 15:10:41

вы на самом деле правы. DbContext это реализация единицы работы шаблона и IDbSet - это реализация шаблона repository.

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

основными причинами использования репозитория обычно являются:

скрыть EF из верхнего слоя

сделать код более проверяемым

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

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

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

Я следую Ayende блог. Если вы когда-либо использовали NHibernate, вы, вероятно, знаете его статьи. Этот парень недавно написал несколько статей против использования репозитория с NHibernate, но NHibernate намного лучше насмешка.

Kendall Bennett · Accepted Answer · 2012-01-04 07:35:36

Я борюсь с теми же проблемами, и насмешка для модульного тестирования слоев EF важна. Но я наткнулся на эту отличную статью, которая объясняет, как настроить объектив EF 4.1 DbContext, чтобы быть из, убедившись, производного DbContext, который реализован обобщенный интерфейс и представляет IDbSet, а не в dbset по. Так как я использую первый подход базу, ведь в нашей базе уже существует, я просто изменил шаблоны T4 используется для создания производного DbContext, чтобы создать его возвращайте интерфейсы IDbSet, а также производные от моего общего интерфейса. Таким образом, все это можно легко высмеять, и вам не нужно реализовывать свою собственную единицу работы или шаблон репозитория. Просто напишите свой сервисный код, чтобы использовать свой общий интерфейс, и когда вы перейдете к модульному тестированию, просто издевайтесь над общим интерфейсом с конкретными тестовыми данными, и вы хорошо идти.

http://refactorthis.wordpress.com/2011/05/31/mock-faking-dbcontext-in-entity-framework-4-1-with-a-generic-repository/

Leniel Maccaferri · Accepted Answer · 2012-05-20 08:35:24

одна из причин создания репозитория заключается в том, что вы можете скрыть реализацию DBSet и DbContext, если вы решите перейти от EntityFramework к чему-то другому или наоборот.

например, я использовал NHibernate и я обернул все вызовы этой структуры внутри моих классов репозитория. Они возвращают IEnumerable для их получения, чтобы быть "универсальными", а мои репозитории имеют стандартные операции CRUD (обновление, удаление и т. д.). Я уже давно перешел на Entity Framework. После этого мне не нужно было ничего менять в моих классах ViewModel или за их пределами, потому что они указывали на мой репозиторий-мне нужно было только изменить внутреннюю часть моего репозитория. Это значительно облегчило жизнь при миграции.

(Я использовал NHibernate, потому что мы подключаемся к ISeries, и в то время не было никаких дорогостоящих аффективных реализаций с использованием EF с ISeries. Единственным доступным было заплатить $ 12,000 IBM за их DB2Connect)