IoC容器，流利的接口循环引用

最好的方法是围绕依赖项注入（构造函数注入）设计应用程序，并在应用程序的启动路径（组合根）处配置容器。理想情况下，您的项目B应该不依赖于DI容器本身，或者项目中最多包含一些引导代码，以允许为该项目创建配置。 当您在启动项目（可能是项目A）中注册容器时，将没有循环引用。 更新 在注释中，您解释了Project B项目仅用于IOC引导。拥有一个引导程序项目没有什么错，因为这将使您所有其他项目都完全避免使用任何IOC容器。如果您有多个库可供多个应用程序（例如，Web应用程序，Web服务和Windows服务使用的业务层）重用，则通常会使用引导程序项目。 引导程序项目应该仅引导可重用项目的“静态”依赖项。配置随应用程序项目而变化的事物是没有意义的。接下来，由于引导程序本身就是一个可重用的项目，因此您不希望它依赖于您的一个应用程序项目，因为那将是您要交换的部分。在运行Windows服务时引用ASP.NET Web应用有什么用？那太令人讨厌了。 引导程序项目在具有多个应用程序项目时特别有用，但这并不意味着您不能在单个应用程序解决方案中使用它。正如您已经注意到的，这里仍然适用相同的规则，因为您最终将得到循环引用。 换句话说，解决方案很简单：让引导程序仅引导下面项目的依赖关系，而不是应用程序项目。但是，如果应用程序项目是您仅有的项目，则不需要引导程序项目。它不会工作。