我们使用MVC架构，其模型由BLL和DAL组成。
因此，我们为我们的系统开发“模块”，我正在实现的特定模块使用了大量相同的依赖项。特别是一个类有20个依赖项。目前，默认构造函数正在创建一个默认的具体实现，我们还有第二个构造函数[第一个使用]，允许一个注入自己的依赖项（即测试）。
20个构造函数参数看起来像一个非常讨厌的代码味道。 另一件烦人的事情是，当我开始添加常用功能时，我需要在每个类中添加构造函数代码和字段，经常反复重复相同类型的代码。
IoC容器似乎是一个自然的解决方案，但问题是我要走多远？我是否包含DAL依赖项和BLL依赖项？那么“助手”或“服务”依赖呢？似乎在某个时刻我只是重新创建了“命名空间”结构，能够像静态类一样引用我的类，此时我会质疑我实际获得的内容。
我在思考这个问题时遇到了麻烦。有没有人有优雅的解决方案或建议？
答案 0 :(得分：7)
如果你选择IoC路线（我推荐），我会将所有依赖项都包含在容器中。
好处是您永远不必担心创建这些依赖项，即使它们有很多层深度。
例如，ClassA在其构造函数中包含4个其他类，每个类在其中包含两个其他类，并且每个类至少接受一个DAL引用。
在这种情况下，您只需要引用最高级别图层中的 IoC （“组合根”），这可能是您的用户界面，并说“给我一个对象A的实例” “，然后IoC将自动实例化构建对象图所需的各种依赖项的其他20个实例。
你的课程不再需要担心如何创建他们的依赖关系，如果他们需要的东西他们只是坚持在构造函数中， IoC 将确保它得到它。
我还要评论，即使你使用 IoC ，一个类中的20个依赖项也是一个明确的代码味道。它通常表明课程做得太多，违反了单一责任原则。