针对非平凡项目依赖项推荐的Windsor架构

时间:2017-03-17 05:27:44

标签: c# castle-windsor

我们的解决方案中有大约20个自包含项目。每个项目都是一个独立的组件,并拥有自己的Windsor安装程序。通过这种结构,我们发现我们的Windsor安装程序变得庞大,难以管理和脆弱。

在我们的解决方案中,一些总体项目依赖于其他较小项目的子集,而某些项目依赖于另一个项目。

结构图与此类似,其中箭头表示依赖关系:

enter image description here

不要详细说明图表中每个项目的命名。它们只是为了可管理性和重用问题而分开的不同项目。

我可以看到Windor安装的两种方法是:

  1. 每个组件都会安装其依赖项。在此示例中,API的安装程序安装组件A和组件B.同样,组件A的安装程序安装模块A和模块B,组件B的安装程序安装模块B和模块C.这是我首选的解决方案,因为它提供了整洁的封装。

  2. 顶级项目会在解决方案中安装所有依赖项。在此示例中,API的安装程序将同时安装组件A和B以及所有三个模块。

  3. 第一种方法的缺点是可能多次安装的每个安装程序需要使用Component.For<X>.OnlyNewServices()进行每次注册。这是冗长且容易忘记的,并且确实需要应用于每个注册,以允许应用程序增长和组件重用。

    第二种方法的缺点是项目最终需要了解他们无需了解的组件,并且封装被破坏。

    问题:

    1. Windsor有没有办法设置默认行为,以便多次注册组件?

    2. 或者,是否有一些其他推荐的Windsor架构用于非平凡的依赖(例如,子容器)?

1 个答案:

答案 0 :(得分:0)

我使用Windsor的内置装配扫描优雅地解决了这个问题。现在每个项目只安装项目中定义的组件,不显式安装任何其他安装程序,也不急于解析其他程序集中的组件。

API项目包含:

var container = new WindsorContainer();
container.Install(FromAssembly.InThisApplication());

我们无法管理的安装程序的部分原因是某些安装程序正在尽早解析依赖组件。这是一种反模式并强制执行安装程序。消除这种需求使得应用程序范围的安装变得微不足道。