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

Question

我有一个应用程序，其中包含从 IView（项目 A）继承的视图

我在另一个项目（项目 B）中有 Windsor IoC Container 作为单例

项目 A 引用了项目 B，并对容器进行静态调用以解析特定视图的具体类型

如果我使用 XML 配置来配置我的容器，那么一切都很好。

如果我尝试使用 fluent 接口来配置我的 contrainer，我会得到一个循环引用，因为我现在需要项目 B 来引用项目 A 以指定接口和具体类型

那么使用流畅的界面来解决这个问题的最佳方法是什么？

编辑：

项目 A 在应用启动时有这个：

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

其中 IoC 是 Project B 中定义的静态类

Answer 1

最好的方法是围绕依赖注入（构造函数注入）设计您的应用程序，并在应用程序的启动路径（组合根）处配置容器。理想情况下，您的项目 B 不应该依赖 DI 容器本身，或者最多在项目中有一些允许为该项目创建配置的引导代码。

当您在启动项目（在您的情况下可能是项目 A）中注册容器时，您将没有循环引用。

更新

在 cmets 中，您解释说您的 Project B 项目仅用于 IOC 引导。拥有一个引导程序项目并没有错，因为这将允许您完全清除所有其他项目，而无需使用任何 IOC 容器。如果您有多个库可供多个应用程序重用（例如，Web 应用程序、Web 服务和 Windows 服务使用的业务层），您通常会使用引导程序项目。

但是，引导程序项目应该只引导可重用项目的“静态”依赖项。配置每个应用程序项目更改的内容是没有意义的。接下来，由于引导程序本身是一个可重用的项目，因此您不希望它依赖于您的应用程序项目之一，因为这将是您将要交换的部分。在运行 Windows 服务时引用 ASP.NET Web 应用程序有什么用？那会很糟糕。

当有多个应用程序项目时，引导程序项目特别有用，但这并不意味着您不能在单个应用程序解决方案中使用它。在这里仍然适用相同的规则，因为您最终会得到循环引用，正如您已经注意到的那样。

换句话说，解决方案很简单：让引导程序只引导下面项目的依赖项，而不是应用程序项目。但是，如果应用程序项目是您拥有的唯一项目，则不需要引导程序项目；它不会工作。