我计划为我的新应用程序遵循洋葱架构。
解决方案层次结构如下
我的计划是使用依赖注入进行依赖解析。最初，我想将与 DI 相关的代码放在 Infrastructure 中。但问题是在我映射服务时它会导致循环引用因为实际的服务实现在我的 Web 项目中，并且 Web 项目已经在引用基础设施。我不能将具体服务移动到另一层，因为它违反了洋葱架构的原则（传递依赖）。
任何线索表示赞赏。
答案取决于您如何定义“DI 相关代码”。
如果您将 DI 定义为一组促进松散耦合和关注点分离的原则和模式，那么这些模式（例如构造函数注入）应该应用于应用程序的所有层。就像您将应用 SOLID 原则和其他 OO 最佳实践一样。
如果 DI 是指直接依赖于该容器的特定容器和代码，那么该代码应该只存在于您的应用程序的入口点中。在您的方案中，这是一个 Web 层。或者，如果这是一个控制台应用程序，它可以是一个“主要”程序。应用程序的这一部分称为Composition Root：
很容易理解，每个类都应该通过其构造函数来获取其依赖项，但这将组合类及其依赖项的责任推给了第三方。那应该在哪里？在我看来，大多数人都渴望尽早作曲，但正确的答案是：
尽可能靠近应用程序的入口点。
这个地方称为应用程序的组合根，定义如下：
组合根是模块组合在一起的应用程序中的（最好）唯一位置。
这意味着所有应用程序代码仅依赖于构造函数注入（或其他注入模式），但从不组合。只有在应用程序的入口点，才最终组成了整个对象图。