配置系统的设计指南？

Posted 2023-02-16

【中文标题】配置系统的设计指南？

【英文标题】：Design guidelines for configuration system?

【发布时间】：2011-05-20 20:31:58

【问题描述】：

尽管我为个人项目做过一些桌面应用程序开发，但我的大部分编程都是基于 Web 的应用程序。一个反复出现的设计问题是关于如何管理配置。例如，我们都知道在 ASP.NET 中，web.config 经常用于保存配置信息，无论是生成的还是手动配置的。

在我什至不知道什么是设计模式之前，我就已经实现了本质上是单例模式的东西。我会编写一个静态类，它在启动时会读取配置文件并将信息以及任何自动生成的信息存储在字段中，然后通过某种访问器（属性, get() 方法...)。

我脑海中的某件事一直在告诉我，这不是解决问题的最佳方法。所以，我的问题是，是否有设计配置系统的设计模式或指南？配置系统应该何时以及如何读取配置，以及它应该如何将此信息公开给应用程序的其余部分？应该是单例吗？我不是要求推荐的存储机制（XML vs 数据库 vs 文本文件...），尽管我也对这个问题的答案感兴趣。

【参考方案1】：

听起来不像是警察，但它确实完全取决于您的应用程序。非常简单的应用程序（听起来像您在谈论基于 Web 的应用程序，所以我将跳过胖客户端），通常只需要全局配置（您可以使用 web.config 和单例）和每个用户配置（用户表，并且可能一个链接的配置表或名称/值对表可以处理。

更复杂的应用可能需要可保护和可覆盖的完整配置层次结构。例如，我可能有几个应用程序定义的默认值，可以为用户所属的每个组、用户自己以及最终管理员定义的特定组或用户定义的值覆盖，这些值不能被用户覆盖。

为此，我通常使用单例“根配置”对象，该对象具有公开其他层次结构和每个级别的配置属性的方法。 root 负责解析层次结构，但如果有必要（例如设置配置），您可以自己遍历层次结构以处理特定于层次结构中单个级别的设置。

最后，还有延迟问题。如果您希望配置设置经常更改，那么每次请求它们时从存储中读取它们是最好的，但也是最昂贵的。

如果没有，您可以缓存设置以及“上次读取”日期，并在过期时间后将设置值重新读取到缓存中。

【参考方案2】：

指导方针：

考虑管理设置

可能多久更改一次？ 如何更改它们以及它们是如何做到的？

E、G web.config 更改需要具有技术技能的人员，并导致您的应用在更改时被重置；由系统提供的 UI 访问的 where-as 设置不会有这些问题。

安全

您需要加密任何设置吗？ 您是否需要隔离设置以便只有某些人可以访问某些设置？ 您是否需要对更改进行任何审核？

命名约定

有一些。 我强烈建议使用基于 URI 的方法来设置键 - 这有助于避免不同组件之间的不同设置之间的冲突（可能是当您开始将第三方组件添加到您的系统时 - 或者当您的系统添加到其他人的组件时）。李> 基于 URI 的键还易于维护，因为更容易查看设置适用的内容。 您可以使用不同的命名“架构”，如果可以的话，我喜欢镜像代码结构，但有时您可能想要遵循其他内容，例如业务流程。 不要使用诸如“DatabaseConnection”之类的模棱两可的名称。

基于 URI 的键示例：

   <appSettings>
        <add key="Morphological.RoboMojo.BusinessLogic.IJobDataProvider" value="Morphological.RoboMojo.XmlDataProvider.JobDataProvider, Morphological.RoboMojo.XmlDataProvider"/>
        <add key="Morphological.RoboMojo.BusinessLogic.ITaskDataProvider" value="Morphological.RoboMojo.XmlDataProvider.TaskDataProvider, Morphological.RoboMojo.XmlDataProvider"/>
        <add key="Morphological.RoboMojo.XmlDataProvider.NameAndPathOfDataFile" value="C:\Program Files (x86)\Morphological Software Solutions\RoboMojo\RoboMojoState.txt"/>
        <add key="Morphological.RoboMojo.XmlDataProvider.PathOfDataFileBackups" value="C:\Program Files (x86)\Morphological Software Solutions\RoboMojo\RoboMojoState Backups"/>
        <add key="Morphological.RoboMojo.BusinessLogic.ITaskExecutorProvider" value="Morphological.RoboMojo.TaskExecutorMSRoboCopy.RoboMojo, Morphological.RoboMojo.TaskExecutorMSRoboCopy"/>
        <add key="Morphological.RoboMojo.TaskExecutorMSRoboCopy.LocationOfRoboCopyEXE" value="C:\Windows\System32\RoboCopy.EXE"/>
    </appSettings>

【讨论】：

抱歉，我看不出它比适当的分层配置方案有什么好处。例如，如果你问我，拥有所有那些重复的“形态学”关键字只会有一种非常讨厌的代码味道。 “形态学”对象的简单 XML 可持久对象层次结构，具有返回“RoboMojo”对象的属性，具有返回“BusinessLogic”对象等的属性，似乎更容易处理，配置明智，如以及代码方面。

@drventure：这是一个有趣的概念，我认为它在不需要复杂层次系统的小型应用程序中很有用。例如，对于一个小型桌面应用程序，它可以在带有键/值对的简单配置文件中使用，同时由于伪命名空间仍然保持良好的分离。不过，在大型 Web 应用程序中，分层的 custom config section 可能更易于使用。

@voithos - 正确。分层的东西很好，但有它自己的问题。如果您在任何时候都处于单个文件解决方案中，那么您希望让设置表单变得混乱。

@drventure - 我不同意代码异味问题。配置键与应用配置的位置完全匹配 - 因此系统更易于跟踪且更易于维护。在这种情况下，绝对没有理由添加不必要的层次结构。 “附加”词反映了命名空间，它反映了组件/系统；所以它也减少了以后发生冲突的机会。