配置的统一/Spring或System.Configuration？

Question

如果您已经将团结作为项目的一部分，那么编写传统的配置类是否有意义呢？

这样做似乎是额外的工作，但积极的是更特定于领域的XML标记名和更简洁的XML。但是，当你在两者之间划出界限和一致性的时候，问题就变成了。

在过去，当我将Spring.NET用于IoC时，我将两者混合使用，但我想知道这样做是否只是降低了配置的一致性。当然，如果您还没有将库用于IoC/DI，那么只为运行时配置目的使用它们似乎有点过分，但是如果您使用了，您会采取什么方法呢？

Answer 1

那得看情况。当然了。:-)

配置文件的目的是什么，更重要的是，目标受众是谁？稍后谁将读取或编辑配置文件？

如果主要目的是将应用程序连接起来，并且它是针对开发人员的，并且您的类型有相当好的名称，那么只需使用DI容器配置就可以了。危险在于，您有很多无关的细节，而这些细节并不是真正的germaine来“配置”应用程序本身。例如，如果要更改连接字符串，那么您确实希望将其放在一个地方，并将其明确标记为连接字符串。

这就是为什么我要问观众和目的是什么。有了更具体的标记，简洁的XML标记可以使找到和编辑管理员更容易、更快和不容易出错的地方。

尽管如此，除了用System.Configuration做简单的名称/值对之外，做任何事情都是一个巨大的痛苦。.NET配置类是错误的，严重缺乏文档，并且充满了奇怪的、意想不到的行为。

我建议从容器配置开始，然后花时间显式地设计您的配置模式，集中精力于您的用例并简化编辑。

我不知道春天，所以我不能说它在那里是如何工作的。与团结，这是相当容易混合和匹配。您可以使用API和配置文件，因此将应用程序操作所需的内容放到API调用中，将用户可调整的内容放到配置文件中。这样，并将其划分为单独的容器定义，甚至是单独的配置文件，您就可以将内部连接与管理员应该或需要接触的东西隔离开来。

另外，作为最后手段，Unity模式本身是可扩展的，因此您实际上可以向Unity部分添加标记。但是，这需要使用System.Configuration并将其安装到Unity框架中，因此这是更多的工作。

博士:这里没有一个好的答案。通用DI配置模式具有通用的优点，并且已经编写好了。它的缺点是，它不一定是显而易见的，什么需要调整由一个管理员，以及什么是内部布线细节，将打破严重的事情。自定义配置部分可能需要编写大量的工作，但是如果做得好，管理员可以在不以不明显的方式破坏整个大厦的情况下，为管理员提供清晰而明显的编辑点。

Answer 2

IMO，您不应该使用配置类，而应该使用配置特定的asp.net或dot.net任务，比如压缩或配置http模块，因为它们是不可移植的。它们需要额外的工作，而且--总的来说--是无法测试的。

此外，如果您需要将特性移植到silverlight等其他平台，您必须考虑如何移植这些配置类，以及如何将它们移植到不同的体系结构中。

Answer 3

许多开发人员遵循YAGNI (您不需要它)的方法，因此不会使用xml配置文件，因为它们被认为过于复杂了一个简单的问题。

我更喜欢遵循CMA (涵盖我的a**)方法，并将内容放入xml配置文件中，以允许根据客户的需求/管理分解来灵活地交换dll的进出应用程序！

我所使用的另一种机制是目录搜索器，它扫描指定的目录以查找dll，然后使用反射查找特定的接口实现，这个接口通常有一个简单的方法，比如RegisterServices或Initialize。在codeplex上的WPF & Silverlight复合应用程序中有一个这样的例子，需要查找的接口是IModule。

不管怎么说，我确实觉得使用DI / IoC是确保应用程序模块化和可测试性的最佳方法。是的，它的配置确实需要一些额外的设置工作，但是当你第一次看到一个经理说“我已经和这个合作伙伴谈过了，他们现在要为我们提供这个服务，让它工作”，而你所要做的就是编写一些代码来实现一个接口，然后在一个配置文件中更改一个dll，你就会意识到它给你带来的灵活性。