31 | APIController：定义API的最佳实践
首先看一个传统意义上三层架构定义的 Controller
[HttpPost]
public Task<long> CreateOrder([FromBody]CreateOrderVeiwModel viewModel)
{
var model = viewModel.ToModel();
return await orderService.CreateOrder(model);
}
class OrderService : IOrderService
{
public long CreateOrder(CreateOrderModel model)
{
var address = new Address("wen san lu", "hangzhou", "310000");
var order = new Order("xiaohong1999", "xiaohong", 25, address);
_orderRepository.Add(order);
await _orderRepository.UnitOfWork.SaveEntitiesAsync(cancellationToken);
return order.Id;
}
}
可以看到这里的 Controller 负责模型转换，还负责服务调用，服务里面实际上就是领域模型的操作部分
随着业务逻辑的越来越复杂，Controller 会越来越膨胀，在 DDD 领域驱动设计的理念下，我们更倾向于把应用程序的每一层明确区分，然后层与层之间的界限应该是明确的，在实现上面应该也是隔离的
Controller 这一层负责与前端用户的交互，它主要的责任就是定义输入和输出，实现身份认证，授权功能，它不应该处理领域模型，处理仓储，所以不建议以上的写法，不建议在 Controller 里面写模型转换和服务调用
namespace GeekTime.API.Controllers
{
[Route("api/[controller]")]
[ApiController]
public class OrderController : ControllerBase
{
IMediator _mediator;
public OrderController(IMediator mediator)
{
_mediator = mediator;
}
[HttpPost]
public async Task<long> CreateOrder([FromBody]CreateOrderCommand cmd)
{
return await _mediator.Send(cmd, HttpContext.RequestAborted);
}
[HttpGet]
public async Task<List<string>> QueryOrder([FromBody]MyOrderQuery myOrderQuery)
{
return await _mediator.Send(myOrderQuery);
}
}
}
这里使用了中间者模式 Mediator，它通过把命令发送出去，然后我们在 Commands 目录下面定义了每一个命令的 handler，这样就可以将业务逻辑的部分和 Controller 处理的部分，输入输出定义的部分进行隔离，我们的 Controller 还需要去定义路由的规则，路由验证的规则
再看一下 Controller 的构造函数，从设计上建议 Controller 所依赖的服务都通过它的构造函数注入进来，之前有讲过，通过容器进行属性注入的方式，但这种方式我们并不推荐使用，当一个 Controller 依赖了很多服务的时候，可以发现有一部分服务是大部分的 Action 都会依赖到的，有一部分服务只是个别 Action 依赖到的，这个时候就可以使用 FromServices，而不需要在构造函数里面注入它，这样有个好处是在编写单元测试的时候，可以在容器里面 Mock 所有的服务
public async Task<long> CreateOrder([FromServices] IEventBus eventBus, [FromBody]CreateOrderCommand cmd)
这里不建议使用属性注入的方式来注入服务，是因为使用属性注入的时候，会把这些属性，比如说 IOrderService，有可能由其他代码 set 我们的 OrderService，造成意外的情况，使我们的代码的维护不可控
public IOrderService orderService { get; set; }
还有一个关键的点是建议尽可能定义异步的 action，尽可能地使用 async 和 await 这样的组合来实现我们的代码，这样对提高我们应用程序的吞吐量是有一定的帮助的
总结一下
APIController 实际上是负责了对前端用户的输入输出的定义，它还负责了身份验证，授权，Url 定义的部分
APIController 不应该负责业务逻辑的承载，应该把这些职责交给我们命令处理程序或者说领域服务来定义
再一个我们也讲解了 APIController 在注入服务时的一些方法，通过构造函数的注入，通过 FromServices 的方式获取服务，不建议的做法时使用属性注入的方式注入
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
欢迎转载、使用、重新发布，但务必保留文章署名 郑子铭 （包含链接： http://www.cnblogs.com/MingsonZheng/ ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。
如有任何疑问，请与我联系 (MingsonZheng@outlook.com) 。