Замена сервисного слоя на MediatR - стоит ли это делать? - PullRequest
0 голосов
/ 13 июня 2018

Как вы думаете, было бы разумно заменить мой уровень обслуживания или классы обслуживания на MediatR?Например, мои классы обслуживания выглядят следующим образом:

public interface IEntityService<TEntityDto> where TEntityDto : class, IDto
{
    Task<TEntityDto> CreateAsync(TEntityDto entityDto);
    Task<bool> DeleteAsync(int id);
    Task<IEnumerable<TEntityDto>> GetAllAsync(SieveModel sieveModel);
    Task<TEntityDto> GetByIdAsync(int id);
    Task<TEntityDto> UpdateAsync(int id, TEntityDto entityDto);
}

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

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

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

В настоящее время моя логика в основном CRUD, но перед созданием, обновлением и удалением происходит множество пользовательских логик.

Возможнозамена моего сервиса выглядела бы так:

public class CommandHandler : IRequestHandler<CreateCommand, Response>, IRequestHandler<UpdateCommand, Response>, IRequestHandler<DeleteCommand, bool>
{
    private readonly DbContext _dbContext;

    public CommandHandler(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public Task<Response> Handle(CreateCommand request, CancellationToken cancellationToken)
    {
        //...
    }

    public Task<Response> Handle(UpdateCommand request, CancellationToken cancellationToken)
    {
        //...
    }

    public Task<bool> Handle(DeleteCommand request, CancellationToken cancellationToken)
    {
        ///...
    }
}

Было бы что-то неправильно делать?

В принципе, я изо всех сил пытаюсь выбрать что-то для моего логического потока:

  • Контроллер -> Сервис -> MediatR -> Обработчики уведомлений -> Хранилище
  • Управлениеer -> MediatR -> Обработчики команд -> Репозиторий

Кажется, что с MediatR у меня не может быть единой модели для создания, обновления и удаления, поэтому один из способов ее повторного использования I 'мне нужно получать запросы вроде:

public CreateRequest : MyDto, IRequest<MyDto> {}        
public UpdateRequest : MyDto, IRequest<MyDto> {} 

или встраивать его в мою команду, например:

public CreateRequest : IRequest<MyDto>
{
    MyDto MyDto { get; set; }
}

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

1 Ответ

0 голосов
/ 23 августа 2018

Отчасти здесь ответили: MediatR, когда и почему я должен его использовать?vs 2017 webapi

Самым большим преимуществом использования MediaR (или MicroBus, или любой другой реализации-посредника) является изоляция и / или выделение вашей логики (одна из причин ее популярности).использовать CQ RS ) и хорошую основу для реализации шаблона декоратора (что-то вроде фильтров ASP.NET Core MVC).В MediatR 3.0 есть встроенная поддержка для этого (см. Поведения ) (вместо использования декораторов IoC)

Вы также можете использовать шаблон декоратора со службами (такими классами, как FooService).И вы можете использовать CQRS и со службами (FooReadService, FooWriteService)

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

Дополнительное чтение:

...