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

如何解决IoC容器，流利的接口循环引用

| 我有一个包含从IView（项目A）继承的视图的应用程序 我在另一个项目（项目B）中将Windsor IoC容器作为Singleton 项目A对项目B的引用，并且对容器进行静态调用以解析特定视图的具体类型 如果我使用XML配置来配置我的容器，那么一切都很好。 如果我尝试使用流利的接口配置约束器，则会得到一个循环引用，因为现在我需要项目B来引用项目A，以便指定接口和具体类型 那么使用流畅的界面实现此目的的最佳方法是什么？ 编辑： 项目A在应用启动时具有以下功能：

IoC.Instance.Start(); // this configures the container from config
IoC.Instance.Container.Resolve<IBootStrapper>().Start();

IoC是项目B中定义的静态类     

解决方法

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