Репозиторий против шаблона обслуживания в DAL: EF и Dapper

Я работаю над проектом, и мне нужно спроектировать DAL. Я использую Entity Framework для большей части проекта и Dapper для некоторых областей, чувствительных к производительности.

Я думал об использовании шаблона репозитория, но тогда EF уже в какой-то мере реализует этот шаблон. Но это не так с Даппером. Тогда мне интересно, правильно ли смешивать шаблоны репозитория и службы в моем DAL? Или это будет пересекать уровень бизнес-логики?

Структура выборки, о которой я думал:

MyProjectName.Main
    Views/
    Controllers/
    Infrastructure/
    ...
MyProjectName.DAL
    DataService.EF/
        fileName.cs
        ...
    DataService.Dapper/
        fileName.cs
        ...

Ответ 1

EF или любой другой ORM не реализует репозиторий. Репозиторий предназначен для развязки Домена из Стойкости. Домен работает с объектами домена, EF/Nhibernate/Dapper и т.д. Работают с сущностями persistence, которые представляют представление OOP для реляционной базы данных.

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

Всегда, ORM - это деталь реализации репозитория. Для приложений CRUD, где у вас действительно нет домена, вы имеете дело непосредственно с db i.e(micro) ORM. В этом случае Repo имеет смысл только как фасад, чтобы придать бизнес-смысл доступу к данным (GetOrders намного легче понять, что целый Linq или 5 строк SQL соединяют 3 таблицы).

Интерфейс репозитория определен там, где он нужен, но реализован в Persistence (DAL). То же, что и для Сервисов, они могут быть определены (как интерфейс) в Домене, а их реализация может быть в DAL. Хотя реализация Репозитория почти всегда является частью DAL, только некоторые службы находятся в DAL, по той простой причине, что им легче выполнять свою работу таким образом. Другие службы могут напрямую использовать репозитории (обычно вводимые через конструктор) и не касаются DAL.

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

Ответ 2

Ознакомьтесь с гибридной реализацией EF + Dapper, которая Bradley Braithwaite создал.

GitHub Repo: https://github.com/bbraithwaite/HybridOrm

Сопутствующая запись в блоге: ORMs: Не переустанавливайте колесо

С точки зрения структурирования слоев проекта, чтобы избежать "кровотечения", вот как он это сделал.

Из сообщения в блоге: Создание репозитория данных с использованием Dapper

Ответ 3

Я могу сказать, что ваша проблема достаточно распространена, и у нее есть общее решение - CQRS (Отслеживание ответственности запросов команд). Этот шаблон широко используется, когда люди практикуют DDD (Domain Driven Design) в своих проектах и сталкиваются с трудностями с помощью some performance-sensitive areas.

Нет никакой разницы, какой ORM вы будете использовать. Это нормально, чтобы иметь разные компоненты, которые извлекают данные.

Вы можете использовать Репозитории и/или Entity Framework и использовать все его функции для most of the project для выполнения C -reate R -ead U -pdate D -элемент.

Но для some performance-sensitive areas вы можете использовать Запросы. Они возвратят DTO, заполненные операциями Dapper ( R -ead).

Ответ 4

Я рекомендую вам посмотреть этот учебник: Entity Framework в Enterprise Здесь автор очень хорошо объясняет структуру Entity Framework и шаблон репозитория, а в конце она реализует 2 репозитория: один для обычного приложения и другой для отключенного приложения. Одна из ее хороших моментов заключалась в том, что ни одна вещь не подходит всем. В основном вы можете адаптировать свой репозиторий к вашей конкретной потребности.

В вашем случае я реализую 2 репозитория: один в верхней части EF и другой для Dapper.