如果我理解正确，那么在经典的3层/ n层体系结构中，目标是最终以这样一种方式将职责分开，即每一层都不必知道较低层内部正在使用/正在使用的内容。
但是，如果每个层（尤其是业务层）中的对象被构造为可测试的，则它们的依赖关系将被定义为其公共合同的一部分（当测试具有第三层对象依赖关系的第二层对象时，对第三层对象进行模拟/存根）层对象并将其提供给第二层对象）。这意味着在实施时，第一层负责获取第三层依赖关系，以用于构造第二层对象。如果它是一个非常平淡的对象，我并不反对，但是如果它是一个需要例如连接字符串的数据访问组件，则第一层不应该对此负责。除此之外，您拥有的依赖关系越多，顶层负责实例化并传入所使用的洋葱切片中每个对象的所有依赖关系。
我见过解决此问题的唯一方法是通过使用IoC，但是我正在解决该选项无法使用的情况。还有其他方法可以将代码结构化为可测试的，但不会遇到实例化/提供顶层每一层依赖关系的问题吗？我应该提到我正在使用网络应用程序。
（我已经过了这篇文章，作为“规则”的复习。）
编辑：我想我可以这样概括问题：在不使用某种IoC容器或引导程序的情况下，有没有一种方法可以将代码构造为可测试的，并且不会违反依赖关系深度原则，这就是洋葱只能引用下面的图层吗？
它与顶层本身无关，而与引导程序有关，引导程序将初始化您的应用程序。根据架构的其余部分，它可以负责在应用程序顶层启动入口点，也可以只是顶层初始化的一部分（甚至与IoC框架一起使用）。
.NET中的示例：
如果您要构建独立的应用程序，则可以将内容初始化为主要执行路径的一部分，只有在所有内容都初始化后，您才会启动入口点。对于Web应用程序或Web服务，此类引导程序通常发生在应用程序启动处理程序中，并且在处理HTTP请求时会使用您的层。
顺便说一句。问题应该是关于IoC容器。与IoC本身无关。IoC是从外部控制内部逻辑的方法-通过注入依赖关系来实现。这是易于测试的应用程序的主要方法。IoC容器是为您构建依赖关系层次结构的框架的一部分。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句