为什么 xml 在 IOC 容器中如此突出？答案

【问题标题】：Why is xml so prominently featured in IOC containers?为什么 xml 在 IOC 容器中如此突出？
【发布时间】：2009-10-09 15:27:28
【问题描述】：

我正在尝试进入 IOC 容器，我注意到其中大量使用 xml 配置。谁能告诉我为什么许多新技术正在转向 xml 配置/编程模型（WCF、WPF、Spring.NET、Unity、Windsor）？似乎 xml 不是指定复杂设置的糟糕选择，最好在代码中执行它，其中的东西是类型安全的并且我们有智能感知。我知道有些人可能会觉得这很有争议，但我真的很好奇为什么这些原本非常酷的先进技术依赖于 xml。

【问题讨论】：

IOC 容器应该从 xml 配置中离开。 Structuremap 的方向已经过去了。 Structuremap 使用流畅的配置。其他一切都在追赶。 ;-)
@mxmissile：在非开发人员需要更改某些内容之前，这很好。此外，围绕 XML 编写配置工具比使用流畅的编码样式更容易。
@Whited，我不明白，我发现写 xml 就像拔指甲一样。从开发人员的角度来看，Fluent 配置似乎具有直观的意义。另外，非开发人员应该接触过这样的东西吗？
@Steve 如果开发人员/服务运营商拜访客户并想要更改配置怎么办？ Xml 配置使他能够在不需要复杂的工具集（编译器、库、环境设置）的情况下进行更改——这只是一个例子。如果你认为你永远不需要它，那么使用代码配置......无论如何，我有很多情况下代码配置会让人头疼。对我来说，从“快速更改”的角度来看，代码配置不如 xml 配置灵活，这对我来说是这个领域最重要的事情。
@Steve ...“可读性”是一个主观的论点，编码风格可能非常不同，并且那里有漂亮的 xml 编辑器（XMLSpy 等）（如果记事本还不够的话）。如果您的配置有问题并且您需要找出问题，那么更重要的是良好的日志输出。这可以由编译器完成拼写错误（代码配置为 1+），但是运行时问题呢？ xml和代码配置同样的问题。

标签： xml ioc-container

【解决方案1】：

我将 Unity 配置移动到 XML 中只是出于一个原因 - 我可以更改配置而无需重新编译我的代码。这在某些情况下非常有用。

【讨论】：

这就是我也喜欢 XML 的原因：不需要重新编译来改变系统的行为（例如，替换依赖项、添加日志记录等）。太糟糕了，Java 家伙有 SpringIDE 之类的东西，但 .Net 仍然没有可比性。所以我们必须使用 XSD 和 UnitTest。 IMO IoC 容器完全可以在代码中配置，而不是通过外部配置文件（Ninject、LinFu？）缺少 IoC 的重要部分。在我看来，属性也不是要走的路：不是从你的类中删除依赖项，而是向 IoC 容器添加一个依赖项。
同意，但是有很多任务不需要XML配置，在这种情况下我更喜欢使用Ninject，因为它很酷=）

【解决方案2】：

这就像你想把东西粘在一起时为什么锤子有一个钢头。

在运行时从声明性配置文件组装应用程序是目标，DI 本身只是实现它的手段。

如果您可以编写配置代码，为什么还要使用 IoC 框架？采用更紧密耦合的设计并为自己省去很多痛苦。

【讨论】：

【解决方案3】：

总的来说，我喜欢 IoC 的流畅界面，正如 mxmissile 建议的那样（我使用 Unity）。

虽然这确实意味着只有开发人员才能更改事物（正如 Matthew Whited 指出的那样），但您希望非开发人员多久能够在您的应用程序中将一个类替换为另一个类?在这些情况下，您可以准备一个简单的配置对话框（由您想要的任何数据存储支持）并获得控制流畅配置的结果。这避免了脆弱性和安全问题。因为如果最终用户搞砸了您的配置文件，那么当应用程序崩溃时，您很可能会受到指责。

我更改配置的主要用例是用于单元测试。在这种情况下，我可以手动将伪造品注入到我的测试类中（这是我通常做的）或重新进行流畅的配置。

【讨论】：

【解决方案4】：

在 IOC 和许多其他“可配置”技术中。

问题是（曾经）XML 成为文档互操作性的标准。

因此，每个人都采用了“新”格式，而不是让每个人都创建自己的格式。

这有一段时间很好，但最终它变得烦人，正如你所指出的那样。

关于在代码中指定它，问题是，有时必须重新编译代码才能使更改生效，而作为 text/plain 的 XML 允许在不重新编译的情况下进行修改。

新格式正在出现，但没有一种格式像 XML 那样产生如此大的影响。

【讨论】：

【解决方案5】：

IoC 容器应被视为以非编程方式部署/配置应用程序的渲染引擎，而不是促进 IoC 设计模式的编程框架。

因此，使用 XML 主要有两个原因：

明确可视化构建的应用程序的语义，而不是语言化 施工程序。
使配置代码在提供增值功能（如配置显示、验证、转换和编辑）的外部异构应用程序之间可互换。 IE。其目的是通过数据集成而不是 API 集成来打开容器。

Fluent API 缺乏数据模型的模式验证，也非常不灵活，无法用于预期的数据集成，因此甚至无法与 XML 配置相媲美。

更多讨论请见XML in IoC containers: A Hell or a Realm。

【讨论】：

【解决方案6】：

因为这是 .net 领域的其他所有人都在做的事情。它从 web.config 开始，人们开始扩展它。但我相信大多数这些技术都支持通过 XML 和代码进行配置。主要区别在于负责部署应用程序以更改配置的非编码人员（例如系统管理员）可以轻松地进行更改。如果需要，那么我认为 XML 仍然是一个可行的选择。我确实相信 .net 世界开始倾向于约定优于配置，而不是将所有内容都放在 XML 配置文件中。

【讨论】：

他们确实支持在代码中执行此操作，但大多数文档都针对在 xml 中执行此操作。
XML 在 web.config 之前就已经无处不在

【解决方案7】：

XML schema 可以通过验证使其成为“强类型”。它如此受欢迎的主要原因之一是它很容易理解，并且几乎任何您想要的编程语言都有如此多的解析器框架。没有什么可以阻止您使用平面文件（例如固定宽度或 CSV）、INI 文件、JSON 文件，甚至可以根据需要使用自定义二进制格式。

XML 也很受欢迎，因为大多数大型框架都有直接的序列化方法，可以将 XML 内容转换为环境原生的复杂对象结构。

【讨论】：

我意识到架构可以是强类型的，但我指的是 xml 中的值。例如，如果我输错了 IOC xml 的接口名称怎么办。通过编译，我会立即知道我犯了一个错误。使用 xml 配置，它会在运行时爆炸，对吗？
正确。当然，如果您使用的是 Visual Studio，您可以将模式扩展添加到 XML 编辑器，这样它就可以为您提供智能和类型检查。我相信其他 XML 编辑器也有类似的能力。

【解决方案8】：

此后，Java 世界中的情况发生了变化，使用注释提供了可能性，但您应该阅读 Google Guice 的作者 Bob Lee 的 I don't get Spring。

编辑：正如评论中所提到的，引用上一篇文章而不提及I was too hard on Spring... 是不公平的。现在已经解决了。感谢您提醒我这一点。

【讨论】：

不要忘记他的后续行动，“我在春天太难了”(crazybob.org/2006/02/i-was-too-hard-on-spring.html)。话虽如此，我喜欢支持这两种配置风格的 DI 框架。

【解决方案9】：

您可以对 xml 进行代码完成。例如，有一个用于 Spring 配置文件的 eclipse 插件，其中显示属性的 javadoc 被设置为工具提示，为类路径中的类名称提供自动完成，标记任何无法在其中解析的 bean 引用当前文件等。

配置文件实际上是 DSL 的一种形式 - 专门用于表达应用程序配置。这种剪裁可以更容易地表达某些东西。例如，当您在 Java 中初始化组件时，您将如何确保正确关闭应用程序（组件必须在其依赖项之前关闭）？您将如何围绕业务服务层配置拦截器？

至于为什么它们是用 XML 完成的，我想 DSL 是必需的，而 XML 受益于现有的基本工具链（编辑器、验证器、解析器......）。

【讨论】：

【解决方案10】：

没有人提到 XML 可以是 XSLT 转换的结果，并且可以在普通 IoC 配置之上以这种方式创建自定义 DSL。这是一种非常强大的方法。

【讨论】：