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

我们使用MVC体系结构和由BLL和DAL组成的模型。设计 - 依赖地狱解决方案？

所以我们为我们的系统开发“模块”，并且我正在实现的特定模块使用了很多相同的依赖关系。一类尤其有20个依赖关系。目前默认的构造函数是创建一个默认的具体实现，我们还有第二个构造函数[第一个使用]允许注入自己的依赖关系（即测试）。

20构造函数参数看起来像一个非常讨厌代码味道。其他讨厌的一点就是经常在我开始添加常用的功能，我需要去添加构造函数代码和领域，各个阶级往往一遍又一遍地重复着同样类型的代码。

IoC容器似乎是一个自然的解决方案，但问题是我能走多远？我是否包含DAL依赖项和BLL依赖项？那么“helper”或“service”依赖关系呢？看起来在某个时候，我只是重新创建了“命名空间”结构，并且能够像静态类一样引用我的类，在这一点上，我怀疑我实际获得的是什么。

我无法通过这个想法。有没有人有一个优雅的解决方案或建议？

来源

2011-10-27 Joshua Enfield

“我很难考虑这个问题”。看看这个教程：https：//github.com/ninject/ninject/wiki –

切线相关：这里是我写的另一个关于减少类的依赖关系的问题的答案。 http://stackoverflow.com/questions/5601920/what-are-your-best-practices-when-using-an-mvc-based-web-framework/5602212#5602212 – Domenic

如果你去IoC路线（我推荐），我会包括你的所有依赖在容器中。

好处是，您无需担心创建这些依赖关系，即使这些依赖关系存在很多图层深度。

例如，ClassA在构造函数中需要4个其他类，每个类都需要两个其他类，每个类都至少需要一个DAL引用。

在这种情况下，您只需在最高层（“组合根”）中引用IoC（可能是您的UI）并说“给我一个对象A的实例”，然后IoC将自动实例化其他20个实例，以获取构建对象图所需的各种依赖关系。

你的类不再需要担心如何创建它们的依赖，如果他们需要的东西，他们只是把它贴在构造和的IoC将确保它得到它。

我也会评论说，即使您使用的是IoC，在一个类中的20个依赖关系也是确定的代码气味。它通常表明班级做得太多，违反了单一责任原则。

来源

2011-10-27 23:01:41

+1 - 强烈同意，国际奥委会是显而易见的（原谅MVC双关语），也适用于“自动”这个词。 – Reddog

+1表示违反SRP。绝对是一个好主意，看看设计。 –

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

回答

相关问题