温莎城堡和动态布线

Question

过去几年，我一直是Windsor的重要用户。在Fluent Registration API之前，我将在Xml Registration和大量AddComponent（）代码之间切换。我们很高兴使用Fluent Registration API和安装程序已经有一段时间了。我从这样的各种着作中得到了印象：

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

Xml注册方法已经失宠，如果在不久的将来某个时候标记为弃用，我不会感到惊讶。

现在，对于我的问题：Fluent Registration API和安装程序可以自动地进行自动布线方案（例如，当我希望Windsor能够弄清楚如何构建我的对象图时）。自动布线是绝大多数IoC用例，但是当自动布线不可能时呢？换句话说，我有多个服务实现，我需要告诉温莎如何构建我的对象图的部分。我已经使用Xml注册方法多次完成这项工作，但是现在有更优选的方法吗？我对Xml注册方法犹豫不决，因为它的未来似乎不确定，但我不知道如何通过Windsor实现这一目标。

我的用例是：

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

这一切看起来非常适合IoC，我们已经拥有了所有的构建模块，但我们希望确保我能够采用Windsor最具前瞻性的方法。

更新 虽然我喜欢功能切换方法，但我最近发现了一个在这方面非常有用的Windsor功能 - Fallback Components。我在这里留下这个编辑给那些可能在以后偶然发现的人。

Answer 1

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

有时虽然您的DI配置依赖于部署时配置，但由于您需要的旋钮数量通常相当小，因此使用配置标志通常比使用完全限定类型名称污染配置文件要好得多。< / p>

或者让我换一种说法，当你的配置文件中放置了大量的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

没有计划在Windsor中废弃或删除XML配置支持。

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

您可以在XML中执行的任何操作都可以在代码中完成（请注意，反之亦然）。

还要记住XML不是全有或全无。有许多方法可以实现您作为示例提供的方案，而无需在XML中进行注册。

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

我过去曾在不同的项目中使用过它们。