我正在做一个 MVC 项目，使用结构图作为 IOC 容器。我们正在做 TDD，我想设置我的依赖项，以便它易于使用，并且易于测试。
我应该如何最好地为下面的虚构插图设置依赖关系图？
- 应用程序 Controller
- Controller
- 身份验证服务
- 用户存储库
- 身份验证服务
- Controller
您是否将用户存储库注入(inject)到 Controller 上，并进一步注入(inject)到身份验证服务中？如果图表更深怎么办 - 您不会在 Controller 上获得大量依赖项吗？
如果您对应用程序 Controller 有依赖性，您是否也会将其注入(inject)到 Controller 上，然后再注入(inject)到基础上？
如果我让容器在图表中间的某个位置解析实例，我将必须设置容器进行测试？这是一件好事还是最好避免？
还有其他我没有看到的方法吗？
最佳答案
您的依赖关系图看起来不错。如图所示，每个类只有一个依赖项
- ApplicationController 依赖于 Controller
- Controller 依赖于 AuthenticationService
- AuthenticationService 依赖于 UserRepository
我意识到这是一个简化的 View ，并且您的实际生产架构会复杂得多，但是 DI(尤其是构造函数注入(inject))的好处在于它违反了Single Responsibility Principle太明显了。
当一个类开始获得太多依赖项时，就表明您应该 refactor to an Aggregate Service .
最终的依赖关系图可能巨大，但每个类只依赖于几个抽象，所以从架构的角度来看，这不是问题。
您永远不必解析图表中间的实例。解决是你的事情do in the Composition Root ，并且(理论上)仅一次。
关于.net - 国际奥委会最佳实践: How to best manage dependency graph?，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2297512/