DDD 和构造函数爆炸

Question

我正在使用 ASP.NET MVC 练习 DDD，遇到这样的情况：我的控制器对不同的服务和存储库有许多依赖项，并且测试变得非常乏味。

一般来说，我为每个聚合根都有一个服务或存储库。考虑一个页面，该页面将列出客户及其订单以及不同套餐和卖家的下拉列表。所有这些类型都是聚合根。为此，我需要一个 CustomerService、OrderService、PackageRepository 和 UserRepository。像这样：

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

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

也许我的服务层处理方式是错误的；我可以有一个 CustomerService 来处理这一切，但我的服务构造函数将会爆炸。我认为我太违反了 SRP。

Answer 1

我认为我过多地违反了 SRP。

宾果游戏。

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

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

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

另外，现在控制器及其依赖项之间的关系很清晰，逻辑已从控制器中删除，查询和命令类更专注于各自的职责。

是的，这确实会导致类和文件的爆炸。采用正确的面向对象编程往往可以做到这一点。但是，坦率地说，更容易查找/组织/管理的是数十个其他半相关函数的文件中的函数或数十个半相关文件的目录中的单个文件。我认为后者毫无疑问。

更好的代码最近有一篇博客文章几乎符合我在 MVC 应用程序中组织控制器和命令的首选方式。

Answer 2

那么您可以通过使用 RenderAction 轻松解决这个问题。只需创建单独的控制器或在这些控制器中引入子操作即可。现在在主视图中使用所需的参数调用渲染操作。这将为您提供一个很好的合成视图。

Answer 3

为什么不为这种情况提供一个服务来为您返回视图模型呢？这样，尽管您的服务可能具有单独的依赖项，但控制器中只有一个依赖项

Answer 4

.net 中的依赖注入一书建议引入“外观服务”，如果您觉得构造函数参数太多，您可以将相关服务组合在一起，然后注入外观。

Answer 5

更新：我终于有了一些空闲时间，所以我最终为我在下面的帖子中讨论的内容创建了一个实现。我的实现是：

public class WindsorServiceFactory : IServiceFactory
{
    protected IWindsorContainer _container;

    public WindsorServiceFactory(IWindsorContainer windsorContainer)
    {
        _container = windsorContainer;
    }

    public ServiceType GetService<ServiceType>() where ServiceType : class
    {
        // Use windsor to resolve the service class.  If the dependency can't be resolved throw an exception
        try { return _container.Resolve<ServiceType>(); }
        catch (ComponentNotFoundException) { throw new ServiceNotFoundException(typeof(ServiceType)); }
    }
}

现在所需要做的就是将我的 IServiceFactory 传递到我的控制器构造函数中，现在我可以保持构造函数干净，同时仍然允许简单（灵活）的单元测试。更多详细信息可以在我的博客 博客 如果您有兴趣。

---

I have noticed the same issue creeping up in my MVC app, and your question got me thinking of how I want to handle this. As I'm using a command and query approach (where each action or query is a separate service class) my controllers are already getting out of hand, and will probably be even worse later on.

考虑到这一点后，我认为我要考虑的路线是创建一个 SerivceFactory 类，它看起来像：

public class ServiceFactory
{
    public ServiceFactory( UserService userService, CustomerService customerService, etc...)
    {
        // Code to set private service references here
    }

    public T GetService<T>(Type serviceType) where T : IService
    {
        // Determine if serviceType is a valid service type, 
        //  and return the instantiated version of that service class
        //   otherwise throw error
    }
}

请注意，我是在 Notepad++ 中临时写的，所以我很确定我GetService 方法的泛型部分在语法上是错误的，但这是总体思路。那么你的控制器最终将看起来像这样：

public class OrderController {
    public OrderController(ServiceFactory factory) {
        _factory = factory;
    }
}

然后你将让 IoC 实例化你的 ServiceFactory 实例，并且一切都应该按预期工作。

这样做的好处是，如果您意识到必须在控制器中使用 ProductService 类，则根本不必弄乱控制器的构造函数，只需调用 _factory.GetService() 在操作方法中获取您想要的服务。

最后，这种方法仍然允许您通过在测试代码中使用模拟服务创建一个新的 ServiceFactory 来模拟服务（这是使用 IoC 并将它们直接传递到控制器的构造函数的重要原因之一）传入（其余为空）。

我认为这将在灵活性和可测试性的最佳世界中保持良好的平衡，并将服务实例化保持在一个位置。

全部输入后，我真的很高兴回家并在我的应用程序中实现它:)