中介者模式-在控制器中还是在应用程序服务中？ [asp.net网络api]

问题描述

在我的下一个项目中，我想使用调解器模式（带有mediatr lib）。在我所看到的所有示例中，他们都将其直接注入到控制器中。

我不喜欢这样的情况是：在某些情况下，我想返回的内容不只是201，而是在POST/PUT/PATCH请求之后返回一个URL，例如，完整版的created /更新的资源，我必须在控制器本身中完成所有操作，这对于控制器来说太过分了（我希望它仅用于路由/调度请求）。

所以，我的问题是-直接在控制器中使用调解器是真的惯例吗，还是仅出于示例目的，而在生产代码中，调解器会进入某种应用程序服务层？

解决方法

我已经使用MediatR进行了一些个人项目，到目前为止，我发现我的控制器最终变得非常干净，并遵循非常简单，可预测的模式。

在中介程序的配置中，您告诉它哪些项目包含请求或通知处理程序。 可能与您的API位于同一项目中，但可能是一个完全独立的项目。当然，它不必在控制器本身中。

然后，将实际的中介程序像记录程序一样注入到控制器中，因此您可以向其发送消息。控制器不在乎哪个项目或服务层处理那些消息，这是中介者要知道的，但是如果您使用的是IRequest，则可以在控制器中等待响应。 （如果您使用的是INotification，则可能会因此而采取多种措施。）

无论如何，我几乎所有的控制器方法都或多或少遵循了这种基本模式。如您所见，这是从GET返回一个对象，但是相同的原理也适用于任何其他动词：

public async Task<IActionResult> GetItemByReference(string reference)
{
    try
    {
        IItem item =
            await this.Mediator.Send(
                new GetItemByReferenceRequest()
                {
                    Reference = reference,});

        if (item == null)
        {
            return this.NotFound();
        }

        return this.Ok(item);
    }
    catch (ArgumentException ex)
    {
        return this.BadRequest(ex.Message);
    }
}

从解决方案的角度来看，我最终得到了类似的结果：

• “ UI”项目，可以是MVC或API项目。
• 一个包含所有mediatr请求对象的项目。
• 一个或多个执行请求处理的项目。

如果需要更改请求的处理方式，则可以创建一个新的处理程序项目，并在中介程序配置期间将其指向该新项目，或者更新现有的处理程序项目。

我希望这表明我发现MediatR是一种很好的方法，可以根据我自己的经验将问题分离出来，并帮助您决定是否使用它！