设计 - 依赖地狱解决方案?

Jos*_*eld 0 c# model-view-controller dependency-injection

我们使用MVC架构,其模型由BLL和DAL组成.

因此,我们为我们的系统开发"模块",我正在实现的特定模块使用了大量相同的依赖项.特别是一个类有20个依赖项.目前,默认构造函数正在创建一个默认的具体实现,我们还有第二个构造函数[第一个使用],它允许一个注入自己的依赖项(即测试).

20个构造函数参数看起来像一个非常令人讨厌的代码味道.另一个烦人的事情是,当我开始添加常用功能时,我需要在每个类中添加构造函数代码和字段,经常一遍又一遍地重复相同类型的代码.

IoC容器似乎是一个自然的解决方案,但问题是我能走多远?我是否包含DAL依赖项和BLL依赖项?那么"助手"或"服务"依赖呢?似乎在某个时刻我只是重新创建"命名空间"结构,能够像静态类一样引用我的类,在这一点上我质疑我实际上正在获得什么.

我在思考这个问题时遇到了麻烦.有没有人有一个优雅的解决方案或建议?

Dyl*_*ith 7

如果您使用IoC路由(我建议),我会将所有依赖项包含在容器中.

好处是您永远不必担心创建这些依赖项,即使它们有很多层深入.

例如,ClassA在其构造函数中包含4个其他类,每个类在其中包含两个其他类,并且每个类至少接受DAL引用.

在这种情况下,您只需要在最高级别层("组合根")中引用IoC,它可能是您的UI,并说"给我一个对象A的实例",然后IoC将自动实例化另一个构造对象图所需的各种依赖关系的20个实例.

你的类不再需要担心如何创建它们的依赖项,如果它们需要它们只是将它放在构造函数中,而IoC将确保它获得它.

我还要评论一个类中的20个依赖项是一个明确的代码味道,即使你使用的是IoC.它通常表明班级做得太多,违反了单一责任原则.

  • 提及违反SRP的+1.绝对是一个好主意,看看设计. (3认同)