推荐用于非平凡项目依赖项的 Windsor 架构
Recommended Windsor architecture for non-trivial project dependencies
我们的解决方案中有大约 20 个独立的项目。每个项目都是一个独立的组件，并有自己的 Windsor 安装程序。使用这种结构，我们发现我们的 Windsor 安装程序变得庞大、难以管理且脆弱。
在我们的解决方案中，一些总体项目依赖于其他较小项目的子集，而一些项目又依赖于另一个。
结构图与此类似，其中箭头表示依赖关系：
不要纠结于图表中每个项目的命名。它们只是出于可管理性和重用问题而分开的不同项目。
我可以看到的两种安装 Windor 的方法是：
每个组件安装其依赖项。在此示例中，API 的安装程序安装组件 A 和组件 B。同样，组件 A 的安装程序安装模块 A 和模块 B，组件 B 的安装程序安装模块 B 和模块 C。这是我的首选解决方案，因为它提供简洁的封装。
顶级项目安装解决方案中的所有依赖项。在此示例中，API 的安装程序安装组件 A 和 B，以及所有三个模块。
第一种方法的缺点是，每个 可能 安装多次的安装程序每次注册都需要使用 Component.For<X>.OnlyNewServices()。这是冗长且容易忘记的，确实需要应用于每个注册以允许应用程序增长和组件重用。
第二种方法的缺点是项目最终需要了解他们不关心的组件知识，并且封装被破坏。
问题：
在 Windsor 中有没有办法设置 默认 行为以便组件可以注册多次？
或者，对于非平凡的依赖项（例如，子容器），是否有其他推荐的 Windsor 架构？
我已经使用 Windsor 的内置程序集扫描优雅地解决了这个问题。每个项目现在只安装项目中定义的组件，不会显式安装任何其他安装程序，也不会急切地解析来自其他程序集的组件。
API 项目包含：
var container = new WindsorContainer();
container.Install(FromAssembly.InThisApplication());
我们的安装程序难以管理的部分原因是一些安装程序正在对依赖组件进行早期解析。这是一种反模式并强制执行安装程序顺序。删除此需求使应用程序范围内的安装变得微不足道。
我们的解决方案中有大约 20 个独立的项目。每个项目都是一个独立的组件，并有自己的 Windsor 安装程序。使用这种结构，我们发现我们的 Windsor 安装程序变得庞大、难以管理且脆弱。
在我们的解决方案中，一些总体项目依赖于其他较小项目的子集，而一些项目又依赖于另一个。
结构图与此类似，其中箭头表示依赖关系：
不要纠结于图表中每个项目的命名。它们只是出于可管理性和重用问题而分开的不同项目。
我可以看到的两种安装 Windor 的方法是：
每个组件安装其依赖项。在此示例中，API 的安装程序安装组件 A 和组件 B。同样，组件 A 的安装程序安装模块 A 和模块 B，组件 B 的安装程序安装模块 B 和模块 C。这是我的首选解决方案，因为它提供简洁的封装。
顶级项目安装解决方案中的所有依赖项。在此示例中，API 的安装程序安装组件 A 和 B，以及所有三个模块。
第一种方法的缺点是，每个 可能 安装多次的安装程序每次注册都需要使用 Component.For<X>.OnlyNewServices()。这是冗长且容易忘记的，确实需要应用于每个注册以允许应用程序增长和组件重用。
第二种方法的缺点是项目最终需要了解他们不关心的组件知识，并且封装被破坏。
问题：
在 Windsor 中有没有办法设置 默认 行为以便组件可以注册多次？
或者，对于非平凡的依赖项（例如，子容器），是否有其他推荐的 Windsor 架构？
我已经使用 Windsor 的内置程序集扫描优雅地解决了这个问题。每个项目现在只安装项目中定义的组件，不会显式安装任何其他安装程序，也不会急切地解析来自其他程序集的组件。
API 项目包含：
var container = new WindsorContainer();
container.Install(FromAssembly.InThisApplication());
我们的安装程序难以管理的部分原因是一些安装程序正在对依赖组件进行早期解析。这是一种反模式并强制执行安装程序顺序。删除此需求使应用程序范围内的安装变得微不足道。