设计-依赖地狱解决方案
本文关键字：解决方案 地狱 依赖 设计 | 更新日期: 2023-09-27 18:12:32
我们使用MVC架构，模型由BLL和DAL组成。
因此，我们为我们的系统开发"模块"，而我正在实现的特定模块使用了许多相同的依赖项。其中一个类有20个依赖项。目前默认构造函数正在创建一个默认的具体实现，我们还有第二个构造函数(第一个构造函数使用的)，它允许我们注入自己的依赖项(即测试)
20个构造函数参数看起来像一个相当讨厌的代码气味。另一件恼人的事情是，当我开始添加公共功能时，我经常需要在每个类中添加构造函数代码和字段，经常一遍又一遍地重复相同类型的代码。
IoC容器似乎是一个自然的解决方案，但问题是我能走多远?我是否包括DAL依赖关系和BLL依赖关系?那么"helper"或"service"依赖关系呢?似乎在某一点上，我只是重新创建"命名空间"结构，使其能够像引用静态类一样引用我的类，在这一点上，我质疑我实际上获得了什么。
我想不通这个问题。有没有人有优雅的解决方案或建议?
如果您选择IoC路线(这是我推荐的)，我会将所有依赖项包含在容器中。
这样做的好处是，你永远不必担心创建这些依赖关系，即使有大量的依赖关系。
e。g ClassA在它的构造函数中接受其他4个类，每个类在它们的构造函数中接受另外两个类，每个类至少接受一个DAL引用。
在这种情况下，你只需要在你的最高级层("组合根")中引用IoC，这可能是你的UI，并说"给我一个对象A的实例"，然后IoC将自动实例化其他20个实例，用于构建对象图所需的各种依赖关系。
你的类不再需要担心如何创建他们的依赖，如果他们需要什么，他们只是把它放在构造函数和IoC将确保它得到它。
我还想说，一个类中有20个依赖项是一种明确的代码气味，即使你使用的是IoC。它通常表明类做了太多的事情，违反了单一职责原则。