我为我的MVC分层应用程序使用依赖注入。当我的业务逻辑类需要太多依赖项（5+接口参数）时，我遇到了问题。结果，类构造函数变得宽泛而丑陋。是否可以使用DI图案？我可以将业务类拆分为不太复杂的（并且参数数量可以接受），但是控制器内部的参数数量会增加（因为它们需要更多的商务对象）。
如何应对这种情况？
答案 0 :(得分：2)
构造函数过度注入是code smell，因为它通常表示违反了Single Responsibility Principle。换句话说，如果一个类有很多依赖关系，那么它就表明它有多个职责;它做得太多了。做得太多的课程很难理解，测试和维护。
我认为通过拆分业务逻辑类，你走在正确的轨道上。我发现在这方面非常有效的模式是为每个业务逻辑类提供一个单一（公共）方法，并让它们实现一个单一用例。请查看command/handler pattern作为示例。
但现在您将问题转移到控制器上，但就像业务层中的类一样，表示层中的控制器类也是如此：如果它们有很多依赖项，它们可能有很多代码，成为一个维护问题。
但就像拆分你的BL课程一样，你可以为你的控制器做同样的事情。没有人说控制器应该有很多动作方法和很多代码。您可以在ASP.NET MVC中创建多个使用相同视图模型和相同视图的控制器。此视图应放在Shared文件夹中并清楚地命名，以便MVC可以找到该视图。在使用ASP.NET MVC时，我发现在所有情况下都不是那么令人愉快，但是不要让你的演示框架决定你的设计。关注SOLID principles;其余部分也是如此。
另一种选择是从控制器中提取aggregate services。仔细查看控制器中的代码。您经常会看到组合使用了一组依赖项。使用使用它们的代码将这些依赖项提取到一个新类中，然后将该类注入到控制器的构造函数中。如果你的课程太大，你可能会错过抽象。找到正确的抽象通常并不容易，而且通常需要一些时间才能找到正确的名称。您会看到我多次更改此类聚合服务的名称，将逻辑移入和移出它，直到感觉正确为止。不要害怕尝试这个。