DDD, CQRS, луковая архитектура, ядро ​​ef для приложения уровня предприятия - PullRequest
Новая
       54

DDD, CQRS, луковая архитектура, ядро ​​ef для приложения уровня предприятия

0 голосов
/ 20 сентября 2019

Недавно я обнаружил, что следующий подход прекрасно работает для многих проектов, над которыми я работал.Проблема, однако, в том, что я прочитал, что ядро ​​DbContext само по себе является UoW, и я НЕ должен создавать свои собственные UoW и репозитории.Но в таком случае я не могу абстрагировать свой уровень персистентности от уровня логики приложения.

TL; DR вопрос: Можно ли НЕ иметь собственных репозиториев и не иметь UoW и все еще следовать упомянутой архитектуре с DbContext как UoW?

Моя архитектуракак следует:

Уровень 1 (самый внутренний): агрегаты, сущности, классы доменов POCO, объекты значений

Уровень 2: Доменные службы

Уровень 3: Службы приложений (команды CQRS, запросы, обработчики) и интерфейсы репозитория

Уровень 4A: (уровень персистентности) Реализация репозитория (DbContext)вставлено здесь) EF Core mappings (ORM mappings)

Уровень 4B: Asp MVC API (DI зарегистрирован здесь)

Контроллеры API просто выдают команды и запросы (через MediatR).

Преимущество вышеуказанного подхода состоит в том, что ядро ​​приложения (уровни 1, 2 и 3) полностью абстрагировано от персистентности.Недостатком является то, что вам действительно нужно писать свои собственные репозитории.

Это правильный подход?Или я что-то упустил?

1 Ответ

0 голосов
/ 20 сентября 2019

Почему DbContext - это единица работы?

DbContext фиксирует все изменения, которые вы вносите в одной транзакции, за один раз ( SaveChanges ).

Почему бы вам не создать свой собственный?

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

Следовательно, SaveChanges должно быть достаточно, так зачем создавать свое собственное?

А как насчет абстракции?

Если достаточно SaveChanges, то как намабстрагироваться от нашей зависимости от EF?Интерфейс IUnitOfWork можно представить с помощью одного метода Commit , который можно реализовать, вызвав DbContext.SaveChanges.

И репозитории?

Я не уверен, что понимаю создание репозиториев как жесткое правило.В качестве части абстрагирования вашего уровня персистентности полезно иметь такой уровень, как IRepository, чтобы обеспечить это разделение.Тем не менее, вы не должны создавать хранилище для таблицы .Хранилище на Агрегат является более подходящим.Каждый репозиторий будет загружать весь Агрегат для обеспечения согласованности в пределах границ Агрегата.

...

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

...