1

在过去的几年里，我一直是温莎的忠实用户。在使用 Fluent Registration API 之前，我会在 Xml 注册和大量的 AddComponent() 代码之间切换。很长一段时间以来，我们一直在愉快地使用 Fluent Registration API 和 Installers。我从各种著作中得到了这样的印象：

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

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

现在，对于我的问题：Fluent Registration API 和安装程序在自动连接场景中流畅地工作（即，当我希望 Windsor 弄清楚如何构建我的对象图时）。自动布线是绝大多数 IoC 用例，但是当自动布线不可能时呢？换句话说，我有多个服务实现，我需要告诉 Windsor 如何构建我的对象图的各个部分。我已经用 Xml 注册方法做过很多次了，但是这些天有更首选的方法吗？我对采用 Xml 注册方法犹豫不决，因为它的未来似乎不确定，但我不知道如何通过 Windsor 实现这一目标。

我的用例是：

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

这一切似乎都非常适合 IoC，我们已经准备好所有的构建块，但要确保我正在采用最适合未来的 Windsor 方法。

更新：虽然我喜欢功能切换方法，但我最近发现了一个 Windsor 功能，该功能在此前置后备组件 上非常有用。我将这里的编辑留给以后可能偶然发现的任何人。

4

3 回答 3

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"本身并没有那么好，但这可以通过创建一个强类型的配置助手来简单地解决。

于 2013-06-27T13:07:35.160 回答
0

这个答案也可能有帮助。允许您在运行时动态地提供实现。不过，听起来您不需要那么动态地使用它，而且发生的事情也不太明显。

于 2013-06-27T15:05:57.563 回答
0

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

是的，你是对的，由于其众多缺点，它不是首选方法。

您可以在 XML 中执行的任何操作都可以在代码中执行（请注意，逆向不正确）。

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

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

过去，我在不同的项目中使用过它们中的每一个。

于 2013-06-29T00:39:24.127 回答