建议用于非平凡项目的Windsor体系结构

-1

我们的解决方案中包含大约20个自包含项目。每个项目都是独立的组件，并拥有自己的Windsor安装程序。有了这个结构，我们发现我们的Windsor安装人员变得庞大，难以管理和脆弱。建议用于非平凡项目的Windsor体系结构

在我们的解决方案中，一些覆盖项目依赖于其他较小项目的子集，而一些项目依赖于其他项目。

的结构图将与此类似，在箭头所指的依赖关系：

不要纠缠于每一个项目的图中的命名。它们只是由于可管理性和重用问题而分开的不同项目。

这两种方法，我可以看到的Windor安装：

每一个组件安装它的依赖。在这个例子中，API的安装程序安装了组件A和组件B.同样，组件A的安装程序安装了模块A和模块B，组件B的安装程序安装了模块B和模块C.这是我首选的解决方案，因为它提供了简洁的封装。
顶级项目在解决方案中安装所有依赖项。在这个例子中，API的安装程序安装了组件A和B以及所有三个模块。

第一种方法的下侧是其可以安装不止一次每个安装程序需要使用Component.For<X>.OnlyNewServices()为每个注册。这是冗长且容易遗忘的，并且真正需要应用于每个注册，以允许应用程序增长和组件重用。

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

问题：

是否有温莎的方式来设置默认行为，因此组件可以多次注册？
另外，还有一些其他推荐的温莎建筑的非平凡的依赖项（例如，子容器）？

来源

2017-03-17 nullPainter

对于谁投票决定关闭这一问题作为过宽的人，在文艺青年最爱的版本是“什么是推荐的方法来开发在温莎模块无需注册的碰撞。” – nullPainter

应用程序应该有一个组合根;不是项目：http://blog.ploeh.dk/2011/07/28/CompositionRoot/ – Steven

我指的是Visual Studio项目/程序集。在我的例子中，每个'模块'和'组件'是一个c＃类库。我不确定你的链接是如何相关的。我非常不愿意要求应用程序的入口点（API项目）拥有一个整体的Windsor安装程序，该安装程序不仅安装它的依赖项，还安装这些依赖项的依赖项等等。我不知道马克建议的是否是这样，但如果是的话，对于任何规模的项目来说似乎都不切实际。 – nullPainter

我以温莎内置的组件扫描优雅的解决了这个。现在，每个项目只安装项目中定义的组件，不明确安装任何其他安装程序，也不急于解析其他程序集的组件。

的API项目包括：为我们不可收拾安装的原因

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

部分原因是，一些安装在做相关组件的早日解决。这是一种反模式并强制安装程序顺序。消除这种需求使得整个应用程序的安装变得微不足道。

来源

2017-03-17 21:46:47 nullPainter

建议用于非平凡项目的Windsor体系结构

回答

相关问题