Сервисный уровень по шаблону CQRS

Я пытаюсь создать приложение с использованием шаблона CQRS вместо репозиториев и архитектуры Onion вместо n-слоев с использованием стека MVC5.Сервисный уровень по шаблону CQRS

У меня есть следующие слои прямо сейчас:

Web.Data - Contains DbContext 
Web.Model - POCO classes 
Web.Service - Implementation of Commands and Queries using MediatR 
    --Commands 
    -----Request 
    -----Handlers 
    --Queries 
    -----Request 
    -----Handlers 
Web.UI

Я думал поставить бизнес-логики (например валидация) на классы Handler, но я Recon, что эти классы имеют прямой доступ к EF. Разве это все еще хорошее место для логики?

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

Должен ли я иметь традиционный уровень обслуживания, который принимает интерфейс MediatR, и вместо этого у контроллеров есть интерфейс службы?

источник

2016-02-09 gnaungayan

Мой первый вопрос: ваши модели просто чистые сумки или у них есть _behaviour_? Если последнее, вы должны поместить в них бизнес-логику. Конечно, если, например, проверка проходит через несколько моделей/AR, вам нужен сервис/фасад. Валидация по своей природе - это своего рода-зависит, но вы можете взглянуть на этот [ответ] (http://stackoverflow.com/questions/4776396/validation-how-to-inject-a-model-state- wrapper-with-ninject/4851953 # 4851953) для хороших идей. – kayess

Я предлагаю вам получить prenup, прежде чем принимать решение о своем браке с Entity Framework. Это очень немного больше, чем DataSet 2.0 с убранным интерфейсом моделирования и кучей вещей, которые действительно не должны выполняться внутри прикладного уровня. Я умоляю вас ограничить использование EF его генераторами ADO.NET и гидратацией dto. Рассматривайте это как Linq To Sql над просмотрами и хранимыми процедурами, и вы избежите боли. –

@ K.AlanBates любая структура или техника могут вызвать проблемы в руках неквалифицированных практиков. EF ничем не отличается. Я думаю, что десятки тысяч успешных систем, которые были построены с использованием EF, говорят сами за себя. –

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

источник

2017-03-19 20:17:11 alltej

Сервисный уровень по шаблону CQRS

ответ

Смежные вопросы