Unity/Spring 还是 System.Configuration 进行配置？
如果您已经在项目中使用 Unity，那么编写传统配置类还有什么意义吗？
这样做似乎是额外的工作，但好处是更特定于域的 XML 标记名称和更简洁的 XML。 但问题是，当你在两者和一致性之间划清界限时。
过去，当使用 Spring.NET 进行 IoC 时，我混合使用了两者，但我想知道这样做是否只是降低了配置的一致性级别。 当然，如果您还没有使用 IoC/DI 库，那么仅将它们用于运行时配置目的似乎有些过分，但如果您正在，那么您会采用什么方法 采取？
If you are already using Unity as a part of your project, is there any sense in bothering with writing traditional configuration classes?
Doing so seems like it's extra work, but the positives would be more domain specific XML tag names and more concise XML. But then the question becomes when you draw the line between the two and consistency as well.
In the past, when using Spring.NET for IoC, I've used a mix of the two, but I'm wondering if doing so is just reducing the level of consistency in configuration. Certainly, if you are not already using the libraries for IoC/DI, it seems like overkill to use them simply for runtime configuration purposes, but if you are, what approach would you take?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这取决于。 当然。 :-)
您的配置文件的目的是什么，更重要的是，目标受众是谁？ 稍后谁将读取或编辑配置文件？
如果主要目的是连接应用程序，并且它是针对开发人员的，并且您的类型命名得相当好，那么您可以只使用 DI 容器配置。 存在的危险是您有很多无关的细节，这些细节与“配置”应用程序本身并没有真正的关系。 例如，如果您要更改连接字符串，您确实希望将其放在一个位置，并明确标记为连接字符串。
这就是为什么我问观众和目的是什么。 拥有标记更具体、简洁的 XML 标签可以使管理员更轻松、更快速地查找和编辑正确的位置，并且不易出错。
话虽如此，使用 System.Configuration 执行除简单名称/值对之外的任何操作对于 tuchus 来说都是一个巨大的痛苦。 .NET 配置类存在缺陷，文档严重不足，并且充满了奇怪的、意外的行为。
我建议从容器配置开始，然后花时间明确地设计您的配置模式，专注于您的用例和易于编辑的内容。
我不了解Spring，所以我不能说它在那里是如何工作的。 使用 Unity，混合和匹配变得非常容易。 您可以使用 API 和配置文件，因此将应用程序操作所需的内容放入 API 调用中，并将用户可调整的内容放入配置文件中。 并将其划分为单独的容器定义甚至单独的配置文件，使您能够将内部接线与管理员应该或需要接触的内容分开。
此外，作为最后的手段，Unity 配置模式本身是可扩展的，因此您实际上可以将标签添加到 Unity 配置部分。 但这需要使用 System.Configuration 并将其安装到 Unity 配置框架中，因此工作量更大。
所以，TL;DR：这里没有一个好的答案。 通用 DI 配置模式的优点是通用且已编写。 它的缺点是，管理员需要调整哪些内容，以及哪些内部接线细节会严重破坏事情，这些并不一定很明显。 自定义配置部分可能需要编写大量工作，但如果做得好，将为管理员提供清晰可见的编辑点，而不会以不明显的方式破坏整个大厦。
It depends. Of course. :-)
What is the purpose of your configuration file, and more importantly, who is the intended audience? Who will be reading or editing the configuration file later?
If the main purpose is to wire up the application, and it's aimed at developers, and your types are reasonably well named, then you can get away with just using the DI container configuration. The danger there is that you've got a lot of extraneous detail that isn't really germaine to "configuring" the application per-se. If you were going to change, for example, a connection string, you really want that in one place, clearly labelled as a connection string.
That's why I ask what the audience and purpose is. Having that more specifically labelled, concise XML tags can make finding, and editing, the right spots for an administrator easier, quicker, and less error prone.
Having said that, doing anything other than simple name/value pairs with System.Configuration is a giant pain in the tuchus. The .NET configuration classes are buggy, seriously underdocumented, and full of strange, unexpected behavior.
I would suggest starting with the container configuration just to get going, and then take the time to explicitly design your configuration schema, concentrating on your use cases and ease of editing.
I don't know Spring so I can't say anything about how it works there. With Unity it's pretty easy to mix and match. You can use the API AND configuration files, so put the stuff your application needs to operate into API calls, and the user-tweakable stuff into the config file. That and dividing up into separate container definitions and even separate config files gives you the ability to segregate the internal wiring from the stuff that admins should, or would need to, touch.
Also, as a last resort the Unity config schema is itself extensible, so you could actually add tags to the Unity config section. But that requires doing work with System.Configuration and fitting it into the Unity config framework, so that's even more work.
So, TL;DR: There's no one good answer here. The general DI config schema has the advantage of being general, and already written. It has the disadvantage that it's not necessarily obvious what needs to be tweaked by an admin, and what is internal wiring details that would break things badly. Custom configuration sections are potentially a lot of work to write, but if done well will provide clear and obvious points for admins to edit without breaking the entire edifice in a non-obvious way.
IMO，您不应该使用配置类，而应该在配置特定的 asp.net 或 dot.net 任务中使用 - 例如压缩或配置 http 模块，因为它们不可移植。 它们需要额外的工作，而且总体而言是不可测试的。
此外，如果您需要将功能移植到 silverlight 等其他平台，您必须考虑如何移植这些配置类以及如何将它们适应不同的体系结构。
IMO, you should not use configuration classes but in configuration specific asp.net or dot.net tasks - like compression or configuring http modules, because they are not portable. They require extra work and - overall - are not testable.
More, if you will need to port features to other platforms like silverlight you have to think how to port these configuration classes and how to fit them in different architectures.
许多开发人员遵循 YAGNI（你不会需要它）方法，因此不会使用 xml 配置文件，因为它们被视为使简单问题过于复杂。
我更喜欢遵循 CMA（涵盖我的 a**）方法并将内容放入 xml 配置文件中，以便根据客户的要求/管理崩溃灵活地将 dll 进出应用程序！
我见过的另一种机制是目录搜索器，它扫描指定目录中的 dll，然后使用反射来查找特定的接口实现，该接口通常有一个简单的方法，如 RegisterServices 或 Initialize。 WPF & 中有一个这样的例子。 Codeplex 上的 Silverlight 复合应用程序，要查找的接口是 IModule。
无论哪种方式，我确实认为使用 DI / IoC 是确保您的应用程序模块化且可测试的最佳方法。 是的，它的配置确实需要一些额外的设置工作，但是当您第一次看到经理说“我已经与该合作伙伴交谈过，他们现在将为我们提供这项服务，使其发挥作用”，您所拥有的一切要做的就是编写一些实现接口的代码，然后更改配置文件中的 dll，您将意识到它给您带来的灵活性。
Many developers follow the YAGNI (You aint gonna need it) approach and therefore would not use xml config files as they are seen as overly complicating a simple issue.
I prefer to follow the CMA (cover my a**) approach and put things into xml config files to allow the flexibility of swapping dll's in and out of the application based on customer's requirements / management meltdowns!
One other mechanism I have seen used is a directory searcher which scans a specified directory for dll's and then uses reflection to find a specific interface implementation, this interface usually has a simple method like RegisterServices or Initialize. There is an example of this within the WPF & Silverlight composite application on codeplex, the interface to look for is IModule.
Either way you go I do feel that using DI / IoC is the best approach to ensure you're app is modular and testable. Yes the configuration of it does take a little extra setup work but the 1st time you get a manager saying "I've talked to this partner and they're now going to provide this service for us, make it work" and all you have to do is write some code which implements an interface and then change a dll in a config file, you'll realize the flexibility it gives you.