EntityFramework Core и паттерны "Unit of Work" и "Repository"

Просто о NET | создано: 20.04.2021 | опубликовано: 20.04.2021 | обновлено: 13.01.2024 | просмотров: 5389

Надо ли реализовывать паттерны "Unit of Work" и "Repository" если вы используете EntityFramework Core?

Суть проблемы

Вопрос о необходимости использования паттернов при использовании EntityFramework Core очень частно возникает на просторах сообщества разработчиков на платформе NET, и не только. Ответ простой - и "да", и "нет".

Почему НЕ надо

Вот несколько аргументов в пользу того, чтобы отказаться от реализации паттернов Unit of Work и Repository при использовании EntityFramework Core:

  • EntityFramework Core изолирует ваш код от базы данных (от любой базы данных)
  • DbContext работает по принципу работы паттерна Unit of Work
  • DbSet работает по принципу работы паттерна Repository
  • EntityFramework Core имеет все возможности для Unit-тестирования (в том числе и без использования паттерна Repository)

Почему надо

А вот несколько контрагрументов в ответ на аргументы из предыдущего параграфа:

  • EntityFramework Core не дает возможности получить "из коробки" фильтрованные данные для разбития на страницы (paging), то есть нет методов типа GetPagedList<T> или GetPagedListAsync<T>
  • EntityFramework Core не имеет возможности выдавать данные по запросы на основании ролей (прав доступа или разрешений) при выборки из базы данных, то есть вам так или иначе придется реализовывать выборки на основании ролей в каком-то слое (вы можете его называть как угодно, некоторые его называют Unit of Work).
  • EntityFramework Core реализует доступ к данным, но никоим образом не призван реализовывать механизмы, обслуживающие ваши бизнес-процессы. Реализация бизнес-процессов, обычно начинается на уровне Repository и продолжается на уровне Unit of Work. Значит вам придется базовые принципы реализовывать самостоятельно (принципы доступа, трансформации, агрегации и т.д.). А это уже, так или иначе, Unit of Work, ну или какая-то его часть.

Выводы

Что касается, то я использую Unit of Work и Repository и не просто, а реализую в них логику по разбитию на страницы выдаваемых результатов, а также логику выборке данных с учетом ролей (roles or permissions). Безусловно, вы можете создать свой уровень доступа к данным, назвать каким угодно названием и делать вид, что это не Unit of Work. :)

Ссылки