asp.net-mvc - DDD 和构造函数爆炸

Question

我正在使用 ASP.NET MVC 练习 DDD，遇到了这样一种情况:我的 Controller 对不同的服务和存储库有很多依赖，并且测试变得非常乏味。

一般来说，我为每个聚合根都有一个服务或存储库。考虑一个列出 的页面。客户 ，以及它的订单 和不同的下拉列表包裹 和 卖家 .所有这些类型都是聚合根。为此，我需要一个 客服 , 订单服务 , 包存储库 和 用户存储库 .像这样:

public class OrderController {
    public OrderController(Customerservice customerService, 
      OrderService orderService, Repository<Package> packageRepository, 
      Repository<User> userRepository) 
    {
        _customerService = customerService
        ..
    }
}

想象一下渲染更复杂的 View 所需的依赖项和构造函数参数的数量。

也许我正在接近我的服务层错误；我可以有一个 CustomerService 来处理所有这些，但是我的服务构造函数会爆炸。我认为我违反了 SRP 太多。

Answer 1

I think I'm violating SRP too much.

答对了。

我发现使用命令处理层使我的应用程序架构更清晰、更一致。

基本上，每个服务方法都成为一个命令处理程序类(方法参数成为一个命令类)，每个查询也是它自己的类。

这实际上不会减少您的依赖关系——您的查询可能仍需要相同的服务和存储库来提供正确的数据；但是，当使用像 Ninject 或 Spring 这样的 IoC 框架时，这无关紧要，因为它们会在整个链上注入(inject)所需的内容 - 并且测试应该更容易，因为对特定查询的依赖比依赖更容易填充和测试在具有许多边缘相关方法的服务类上。

另外，现在Controller和它的依赖关系清晰了，逻辑已经从Controller中去掉了，查询和命令类更加关注各自的职责。

是的，这确实会导致类和文件的爆炸式增长。采用适当的面向对象编程往往会做到这一点。但是，坦率地说，更容易找到/组织/管理 - 一个文件中的几十个其他半相关函数的函数或几十个半相关文件目录中的单个文件。我认为后者放下手。

Code Better had a blog post recently这几乎符合我在 MVC 应用程序中组织 Controller 和命令的首选方式。