如果您已经将Unity作为项目的一部分使用，那么编写传统配置类是否有任何意义？
这样做似乎是额外的工作，但积极的是更多特定于域的XML标记名称和更简洁的XML。但是当你在两者之间画出一条线和一致性时，问题就变成了。
过去，当我使用Spring.NET for IoC时，我已经使用了两者的混合，但我想知道这样做是否只是降低了配置的一致性水平。当然，如果您还没有使用IoC / DI库，那么仅仅为了运行时配置而使用它们似乎有些过分，但如果你 ，那么你的方法是什么？ >拿？
答案 0 :(得分：1)
这取决于。当然。 ： - ）
您的配置文件的目的是什么，更重要的是，谁是目标受众？谁将在以后阅读或编辑配置文件？
如果主要目的是连接应用程序，并且它针对开发人员，并且您的类型名称相当合适，那么您只需使用DI容器配置即可。存在的危险是，你有很多无关紧要的细节，并不是真正与“配置”应用程序本身相关的细节。例如，如果您要更改连接字符串，那么您真的希望在一个地方，明确标记为连接字符串。
这就是我问及观众和目的是什么的原因。拥有更具体标记的简洁XML标签可以使管理员找到并编辑正确的位置更容易，更快速，更少出错。
话虽如此，使用System.Configuration做除简单名称/值对之外的任何事情都是一个巨大的痛苦。 .NET配置类是错误的，严重缺乏文档，并且充满了奇怪的，意外的行为。
我建议从容器配置开始，然后花时间明确设计您的配置架构，专注于您的用例和编辑的简易性。
我不知道春天，所以我不能说它在那里如何运作。使用Unity，混合和匹配非常容易。您可以使用API AND配置文件，因此将应用程序需要操作的内容放入API调用中，并将用户可调整的内容放入配置文件中。这又分为单独的容器定义甚至单独的配置文件，使您能够将内部布线与管理员应该或将需要触摸的内容隔离开来。
此外，作为最后的手段，Unity配置架构本身是可扩展的，因此您实际上可以将标签添加到Unity配置部分。但这需要使用System.Configuration 和将其配合到Unity配置框架中，这样才能完成更多工作。
所以，TL; DR：这里没有一个好的答案。一般的DI配置模式具有通用性和已编写的优点。它的缺点是，管理员需要调整的内容并不一定是显而易见的，内部布线细节会破坏什么。自定义配置部分可能需要编写很多工作，但如果做得好，将为管理员提供明确而明显的点，而不会以非显而易见的方式破坏整个大厦。
答案 1 :(得分：0)
IMO，你不应该使用配置类，而是使用配置特定的asp.net或dot.net任务 - 比如压缩或配置http模块，因为它们不可移植。他们需要额外的工作 - 总体而言 - 是不可测试的。
此外，如果您需要将功能移植到其他平台（如Silverlight），您必须考虑如何移植这些配置类以及如何使它们适合不同的架构。
答案 2 :(得分：-1)
许多开发人员遵循YAGNI（您不需要它）的方法，因此不会使用xml配置文件，因为它们被视为过于复杂的简单问题。
我更喜欢遵循CMA（覆盖我的**）方法并将内容放入xml配置文件中，以便根据客户的要求/管理崩溃灵活地将dll交换进应用程序！
我见过的另一种机制是一个目录搜索器，它扫描指定目录中的dll，然后使用反射来查找特定的接口实现，这个接口通常有一个简单的方法，如RegisterServices或Initialize。在WPF和WPF中有一个例子。 Codeplex上的Silverlight复合应用程序，要查找的接口是IModule。
无论哪种方式，我都觉得使用DI / IoC是确保您的应用程序是模块化和可测试的最佳方法。是的，它的配置确实需要一些额外的设置工作，但是第一次你得到一位经理说“我已经和这个合作伙伴谈过了，他们现在要为我们提供这项服务，让它运作”，你所拥有的一切要做的是编写一些实现接口的代码，然后在配置文件中更改dll，你就会意识到它给你带来的灵活性。