我正试图进入IOC容器，我注意到它们中有很多正在使用xml配置。任何人都可以告诉我为什么许多新技术正朝着xml配置/编程模型（WCF，WPF，Spring.NET，Unity，Windsor）发展？似乎xml是指定复杂设置的不良选择，最好在代码中进行，其中事物是类型安全的，我们有智能感知。我知道有些人可能会发现这种说法，但我真的很好奇为什么这些非常酷的先进技术依赖于xml。
答案 0 :(得分：6)
我将Unity配置移动到XML只是出于一个原因 - 我可以在不重新编译代码的情况下更改配置。这在某些情况下非常有用。
答案 1 :(得分：5)
这就像想知道为什么当你把东西粘在一起时锤子有一个钢头。
在运行时从声明性配置文件中组装应用程序是目标，DI本身就是实现它的手段。
如果您可以编写配置，为什么要使用IoC框架？采取更紧密耦合的设计，为您节省很多痛苦。
答案 2 :(得分：4)
一般来说，我喜欢IoC的流畅界面，正如mxmissile建议的那样（我使用Unity）。
虽然这确实意味着只有开发人员可以更改内容（正如Matthew Whited所指出的那样），但是希望非开发人员能够在应用程序中将一个类替换为另一个类的频率？在这些情况下，您可以准备一个简单的配置对话框（由您想要的任何数据存储支持），并使该控件的结果具有流畅的配置。这避免了脆弱性和安全性问题。因为如果最终用户搞砸了你的配置文件，你可能会在应用程序崩溃时受到指责。
我更改配置的主要用例是单元测试。在这种情况下，我可以手动将假货注入我的测试类（这是我通常做的）或重新进行流畅的配置。
答案 3 :(得分：3)
在IOC和许多其他“可配置”技术中。
事实上，XML已成为文档互操作性的标准。
因此，每个人都采用“新”格式，而不是让所有人都创建自己的格式。
这有点好，但最终它变得很烦人，正如你指出的那样。
关于在代码中指定它，有时候，必须重新编译代码以使更改生效，而XML是text / plain允许修改而无需重新编译。
新格式正在出现，但没有一种像XML那样产生影响。
答案 4 :(得分：3)
IoC容器应被视为渲染引擎，以非编程方式部署/配置应用程序，而不是程序化框架，以促进IoC设计模式。
因此，XML的使用主要有两个原因：
Fluent API缺乏数据模型的模式验证，也非常不灵活，无法用于预期的数据集成，因此甚至无法与XML配置相媲美。
有关进一步的讨论，请参阅XML in IoC containers: A Hell or a Realm。
答案 5 :(得分：2)
Java世界已经改变了使用注释提供的可能性，但是你应该阅读I don't get Spring的作者Bob Lee的Google Guice。
编辑：正如评论中所述，引用上一篇文章而不提及I was too hard on Spring...是不公平的。那已经修好了。谢谢你提醒我这件事。
答案 6 :(得分：2)
因为这是其他人在.net领域所做的事情。它从web.config开始，人们开始扩展它。但我相信大多数技术都支持XML和代码配置。主要区别在于非编码人员（如负责部署应用程序的系统管理员）更改配置的难易程度。如果需要，那么在我看来，XML仍然是一个可行的选择。我相信.net世界开始倾向于通过配置而不是将所有内容都放在XML配置文件中。
答案 7 :(得分：2)
XML schema，使其成为“强类型”。它如此受欢迎的主要原因之一是它很容易理解，并且在你想要的几乎任何编程语言中都有很多解析器框架。如果您愿意，没有什么可以阻止您使用平面文件（例如固定宽度或CSV），INI文件，JSON文件甚至自定义二进制格式。
XML也很受欢迎，因为大多数大型框架都有直接的序列化方法，可以将XML内容转换为环境本地的复杂对象结构。
答案 8 :(得分：1)
您可以为xml完成代码。例如，有一个用于Spring配置文件的eclipse插件，其中包括将属性的javadoc设置为工具提示，为类路径中的类的名称提供自动完成，标记任何无法在其中解析的bean引用当前档案等.pp。
配置文件实际上是DSL的一种形式 - 专为表达应用程序配置而定制。这种剪裁可以更容易地表达某些事物。例如，当您在Java中初始化组件时，如何确保正确的应用程序关闭（组件必须在其依赖之前关闭）？您将如何在业务服务层周围配置拦截器？
至于为什么它们是用XML完成的，我认为需要DSL，并且XML具有现有基本工具链（编辑器，验证器，解析器......）的好处。
答案 9 :(得分：1)
没有人提到XML可以是XSLT转换的结果，并且可以在普通的IoC配置之上以这种方式创建自定义DSL。这是一种非常强大的方法。