2

如果您已经在项目中使用 Unity，那么编写传统的配置类有什么意义吗？

这样做似乎是一项额外的工作，但好处是更多特定于域的 XML 标记名称和更简洁的 XML。但是，当您在两者之间划清界限以及一致性时，问题就变成了。

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

4

3 回答 3

1

这取决于。当然。:-)

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

如果主要目的是连接应用程序，并且它面向开发人员，并且您的类型命名合理，那么您可以只使用 DI 容器配置。那里的危险是你有很多无关的细节，这些细节与“配置”应用程序本身并不真正相关。例如，如果您要更改连接字符串，您真的希望将其放在一个位置，清楚地标记为连接字符串。

这就是为什么我问观众和目的是什么。有了更具体的标签、简洁的 XML 标记，管理员可以更轻松、更快捷地查找和编辑正确的位置，并且更不容易出错。

话虽如此，除了简单的名称/值对之外，使用 System.Configuration 做任何事情都是一件非常痛苦的事情。.NET 配置类有缺陷，文档严重不足，并且充满了奇怪的意外行为。

我建议从容器配置开始，然后花时间明确设计您的配置模式，专注于您的用例和易于编辑。

我不知道 Spring，所以我不能说它是如何在那里工作的。使用 Unity，混合和匹配非常容易。您可以使用 API 和配置文件，因此将您的应用程序需要操作的内容放入 API 调用中，并将用户可调整的内容放入配置文件中。分割成单独的容器定义甚至单独的配置文件使您能够将内部布线与管理员应该或需要接触的东西隔离开来。

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

所以，TL;DR：这里没有一个好的答案。通用 DI 配置模式具有通用性和已编写好的优点。它的缺点是不一定很明显需要管理员调整什么，以及哪些内部接线细节会严重破坏事情。自定义配置部分可能需要编写大量工作，但如果做得好，将为管理员提供清晰明了的编辑点，而不会以不明显的方式破坏整个大厦。

于 2010-10-13T22:08:29.603 回答
0

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

此外，如果您需要将功能移植到 Silverlight 等其他平台，您必须考虑如何移植这些配置类以及如何将它们适应不同的架构。

于 2010-10-13T18:40:20.210 回答
-1

许多开发人员遵循 YAGNI（你不需要它）方法，因此不会使用 xml 配置文件，因为它们被视为过于复杂的简单问题。

我更喜欢遵循 ​​CMA（覆盖我的 a**）方法并将内容放入 xml 配置文件中，以允许根据客户的要求/管理崩溃灵活地交换 dll 进出应用程序！

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

无论您采用哪种方式，我都认为使用 DI / IoC 是确保您的应用程序是模块化和可测试的最佳方法。是的，它的配置确实需要一些额外的设置工作，但是第一次你让经理说“我已经和这个合作伙伴谈过了，他们现在将为我们提供这项服务，让它发挥作用”，而你所拥有的一切要做的是编写一些实现接口的代码，然后在配置文件中更改 dll，您将意识到它为您提供的灵活性。

于 2009-06-12T14:25:06.940 回答