温莎城堡和动态布线

Question

我在过去的几年里一直是温莎的用户。在Fluent注册API之前，我会在Xml注册和大量的AddComponent（）代码之间切换。我们一直很高兴地使用Fluent注册API和安装程序很长一段时间。我已经得到了来自不同著作的印象是这样的：

http://docs.castleproject.org/Windsor.XML-Registration-Reference.ashx

该XML注册方法已在不远的失宠，它不会让我感到吃惊，如果它被标记弃用在某些点未来。

现在，对于我的问题：Fluent注册API和安装程序适用于自动布线场景（即，当我想让Windsor知道如何构建我的对象图时）。自动布线是绝大多数IoC用例，但是当自动布线不可行时呢？换句话说，我有一个服务的多个实现，我需要告诉温莎如何构建我的对象图的一部分。我已经使用Xml注册方法做了很多次，但是现在还有更受欢迎的方法吗？由于它的未来似乎不确定，我对使用Xml注册方法犹豫不决，但我不知道如何用Windsor来实现这一点。

我的使用情况是：

• 系统需要能够在QA测试交换实现（即 信贷检查和欺诈检测处理，我们要测试 不会对信贷局API的依赖）
• 我们的 系统中的供应商模式，我们需要在部署时有条件地打开和关闭不同的 实现。

这一切似乎都非常适合IoC，我们拥有所有构建基块，但要确保我正在采取温莎最适合未来的方法。

UPDATE： 虽然我喜欢的功能切换方法，我最近发现一个温莎特点，就是在这方面非常有用 - Fallback Components。我将把这个编辑留给任何可能在后来偶然发现的人。

Answer 1

完全通过XML配置您的DI容器是容易出错，冗长而且太痛苦。 XML配置的可能性始终是您使用基于代码的配置所能做的一个子集;代码总是更具表现力。

虽然您的DI配置取决于部署时间配置，但由于您需要的旋钮数量通常相当小，因此使用配置标志通常比使用完全限定类型名称污染配置文件更好。

或者让我换一种说法，当您的配置文件中有大量DI配置放置在您的配置文件中，因为您可能想在部署时更改它们，请再考虑。许多变化无论如何都需要测试（由开发人员进行测试），所以您不希望操作团队的某个人为此做些调整。当您需要开发人员查看并验证它时，无需重新编译项目有什么优势？这实际上更快吗？无论如何，开发者仍然必须启动应用程序。

这是一种虚假的灵活性，实际上是一个糟糕的界面设计（xml是维护和运营部门的接口）。顺便说一句，你是否需要记录配置文件应如何更改？ 而不是描述在xml文件的中间某处有效的完全限定类型名称的列表，是不是很容易写出所有你要写的内容是“在这个字段中放置'false'以禁用... “？

下面是如何使用的配置开关的一个示例：

bool detectFraught = 
    ConfigurationManager.AppSettings["DetectFraud"] != "false"; 

container.Register(
    Component.For(typeof(IFraughtDetector)).ImplementedBy(
     detectFraught ? typeof(RealDectector) : typeof(FakeDetector)); 

参看配置开关现在如何是一个简单的布尔标志。这使得配置文件更易于维护，因为配置现在是一个简单的布尔开关，而不是完整的类型名称（可能会拼错）。

当然做["DetectFraud"] != "false"本身并不好，但这可以简单地通过创建一个强类型配置助手来解决。

Answer 2

This answer也可能有帮助。允许您在运行时动态地提供实现。虽然，听起来像你不需要动态的，并且不太明显发生了什么。

Answer 3

有没有计划过时或删除温莎的XML配置支持。

是的，你是对的，由于它的许多缺点，它不是一个首选的方法。

您可以在XML中做的任何事情都可以在代码中完成（请注意，inverse是不正确的）。

还要记住XML不是全有或全无。有很多方法可以实现您提供的场景，而无需使用XML进行注册。

• 功能切换
• 条件编译
• 的if/else在installer基础上的appSettings标志
• 其他...

我在不同的项目中使用他们每个人以往。