如果我理解正确的话，在经典的 3 层/n 层架构中，目标是最终以这样一种方式分离职责，即每一层都不必知道较低层内部正在发生什么/正在使用什么层级。
但是，如果每一层(尤其是业务)中的对象被构造为可测试的，则它们的依赖关系被定义为其公共(public)契约的一部分(当测试具有第三层对象依赖关系的第二层对象时，mock/stub输出第 3 层对象并将其提供给第 2 层对象)。这意味着在实现时，第一层负责获取第三层依赖以用于构建第二层对象。如果它是一个非常平淡的对象，我不反对这样做，但如果它是一个需要连接字符串的数据访问组件，那么第一层不应该对此负责。除此之外，您拥有的依赖项越多，顶层就越负责实例化和传递它所使用的洋葱切片中每个对象的所有依赖项。
我见过解决此问题的唯一方法是通过使用 IoC，但我的工作环境是该选项不在桌面上。是否有任何其他方法可以将代码构造为可测试的，但不会面临为顶层中的每一层实例化/提供依赖项的问题？我应该提到我正在使用网络应用程序。
(我已经复习了 this 帖子作为对“规则”的复习。)
编辑:我想我可以这样总结这个问题:在不使用某种 IoC 容器或 Bootstrap 的情况下，是否有一种方法可以将代码构建为可测试的且不违反依赖深度原则，即洋葱中的每一层只能引用它下面的层？
最佳答案
它不是关于顶层本身，而是关于将初始化您的应用程序的 Bootstrap 。根据架构的其余部分，它可以负责在应用程序的顶层启动入口点，也可以只是顶层初始化的一部分(甚至与 IoC 框架一起使用)。
.NET 中的示例:
如果您正在构建独立的应用程序，您可以将一些东西初始化为主要执行路径的一部分，并且只有当所有东西都初始化后，您才会启动您的入口点。在 Web 应用程序或 Web 服务的情况下，此类 Bootstrap 通常发生在应用程序启动处理程序中，并且在处理 HTTP 请求时使用您的层。
顺便说一句。问题应该是关于 IoC 容器的。与 IoC 本身无关。 IoC 是从外部控制内部逻辑的方法——这是通过注入(inject)依赖项来实现的。它是易于测试的应用程序的主要方法。 IoC 容器是为您构建依赖层次结构的框架的一部分。
关于unit-testing - 在不使用 IoC 容器的情况下，是否可以在 3 层或 n 层架构中测试洋葱式代码？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24960203/