我正在尝试进入 IOC 容器,我注意到其中有大量使用 xml 配置。谁能告诉我为什么许多新技术正在转向 xml 配置/编程模型(WCF、WPF、Spring.NET、Unity、Windsor)?似乎 xml 不是指定复杂设置的糟糕选择,最好在代码中执行它,其中的东西是类型安全的并且我们有智能感知。我知道有些人可能会觉得这很有争议,但我真的很好奇为什么这些非常酷的先进技术依赖于 xml。
10 回答
我将 Unity 配置移动到 XML 中只是出于一个原因 - 我可以更改配置而无需重新编译我的代码。这在某些情况下非常有用。
这就像想知道为什么当你宁愿把东西粘在一起时锤子有一个钢头。
目标是在运行时从声明性配置文件组装应用程序,DI 本身只是实现它的手段。
如果您可以编写配置代码,为什么还要使用 IoC 框架?采用更紧密耦合的设计并为自己省去很多痛苦。
一般来说,我喜欢 IoC 的流畅接口,正如 mxmissile 建议的那样(我使用 Unity)。
虽然这确实意味着只有开发人员才能更改事物(正如 Matthew Whited 指出的那样),但您希望非开发人员多久能够在您的应用程序中将一个类替换为另一个类?在这些情况下,您可以准备一个简单的配置对话框(由您想要的任何数据存储支持)并获得控制流畅配置的结果。这避免了脆弱性和安全问题。因为如果最终用户搞砸了您的配置文件,那么当应用程序崩溃时,您很可能会受到指责。
我更改配置的主要用例是用于单元测试。在这种情况下,我可以手动将伪造品注入我的测试类(这是我通常做的)或重新进行流畅的配置。
在 IOC 和许多其他“可配置”技术中。
事情是(曾经)XML 成为文档互操作性的标准。
因此,不是让每个人都创建自己的格式,而是每个人都采用了“新”格式。
正如您所指出的,这有一段时间很好,但最终变得烦人。
关于在代码中指定它,问题是,有时必须重新编译代码才能使更改生效,而 XML 是 text/plain 则允许在不重新编译的情况下进行修改。
新格式正在出现,但没有一种格式能像 XML 那样产生如此大的影响。
IoC 容器应被视为以非编程方式部署/配置应用程序的渲染引擎,而不是促进 IoC 设计模式的编程框架。
因此,使用 XML 主要有两个原因:
- 显式地可视化构建应用程序的语义,而不是用语言表达构建过程。
- 使配置代码在提供增值功能(如配置显示、验证、转换和编辑)的外部异构应用程序之间可互换。即目的是通过数据集成而不是API集成来打开容器。
Fluent API 缺乏数据模型的模式验证,并且在用于预期的数据集成方面也非常不灵活,因此甚至无法与 XML 配置相媲美。
有关进一步讨论,请参阅IoC 容器中的 XML:地狱或领域。
因为这是 .net 领域的其他所有人都在做的事情。它从 web.config 开始,人们开始扩展它。但我确实相信这些技术中的大多数都支持通过 XML 和代码进行配置。主要区别在于负责部署应用程序以更改配置的非编码人员(例如系统管理员)可以轻松地进行更改。如果需要,那么我认为 XML 仍然是一个可行的选择。我确实相信 .net 世界开始倾向于约定优于配置,而不是将所有内容都放在 XML 配置文件中。
可以验证XML 模式,从而使其成为“强类型”。它如此受欢迎的主要原因之一是它很容易理解,并且几乎任何你想要的编程语言都有很多解析器框架。没有什么可以阻止您使用平面文件(例如固定宽度或 CSV)、INI 文件、JSON 文件,甚至可以根据需要使用自定义二进制格式。
XML 也很流行,因为大多数较大的框架都有直接的序列化方法,可以将 XML 内容转换为环境原生的复杂对象结构。
此后,Java 世界中的情况发生了变化,使用注释提供了可能性,但您应该阅读Google Guice的作者 Bob Lee 的我没有得到 Spring。
编辑:正如评论中提到的,引用上一篇文章而不提及我对 Spring 太难了是不公平的...... 现在已经解决了。谢谢你提醒我这一点。
You can have code completion for xml. For instance, there is an eclipse plugin for Spring configuration files that among other things shows the javadoc of the property being set as tooltip, offers auto-completion for the names of classes in your classpath, marks any bean references that could not be resolved within the current file etc. pp.
Configuration files are actually a form of DSL - tailored to express application configuration. This tailoring allows to express certain things more easily. For instance, how would you ensure proper application shutdown (a component must be shut down before its depedencies) when you initialize components in Java? How would you configure an interceptor around your business service layer?
As for why they are done in XML, I guess a DSL was required, and XML had the benefit of an existing rudimentary toolchain (editors, validators, parsers, ...).
没有人提到 XML 可以是 XSLT 转换的结果,并且可以在普通 IoC 配置之上以这种方式创建自定义 DSL。这是一个非常强大的方法。