用于应用程序配置的Xml与数据库

Question

我的应用程序配置非常分层，非常适合单个XML。 很快（YAGNI，Yeh）这些信息的一部分将远程被其他应用程序使用，这需要一个数据库。

因此，我开始设计数据库表并将它们映射回应用程序的类层次结构（使用EF）。然而它成了维护的噩梦。

我很想听听其他人在考虑这个问题时的经验，谢谢。

Answer 1

我们有很好的经验，可以将配置存储在数据库中，用于长期运行的应用程序（如网站和服务）。优点：

• 您可以远程安全地编辑配置（用户/密码）
• 应用程序可以自动或通过信号（ping网页或在某处创建空文件）轻松获取更改（select max(lmod) from config）。
• 应用程序每个环境（dev，test，prod）只需要一个配置项：要使用的DB。如果您有应用程序服务器，则所有环境都可以免费配置您的应用程序。

如果你有一个带有默认值，列表和继承的复杂的分层配置结构，那么主要的问题是编辑。我们的解决方案：

• 配置表包含以下行：Application varchar（32），Key varchar（512），Value varchar（4096）
• 每个环境一个数据库（本地开发人员机器，开发测试，集成测试，生产）
• 密钥是分层的（option.suboption .... name）
• 默认值使用“option。 .name”（例如，“jdbc。 .driver”，因为我们只使用一种类型的数据库）
• 列表存储为字符串，以换行符分隔。
• 地图以字符串形式存储，“name = value \ n”
• 有一个实现可以从文件中读取配置（用于单元测试）。将键的每个层次结构映射到元素（......）

Config对象隐藏了这些细节，因此应用程序只适用于对象。

特殊类负责在发生更改时重新读取配置。通常，我们会在一天中的某个时间更新配置，并且定时作业将在数小时后重新加载。这样，我们就不需要同步配置方法了。

但备份和更改历史记录是一个问题。我们通过在VCS中使用XML文件来修复它，然后将其“上传”到数据库中。这样，我们可以在上传之前验证生产配置（通过在开发人员计算机上使用一组特殊的单元测试）。当它在夜间被激活时，它通常会立即起作用，负责应用程序的操作员只需进行一些测试。

Answer 2

IMHO配置应该存在于文件中，文件适合人们使用，并且它们适用于计算机。数据库可以很好地处理大数据，但它们对人类的东西来说太过分了。这两者通常是相互排斥的，当你尝试将它们组合起来时，就会得到类似注册表的内容 - uggh。

为什么不将配置保留在文件中，并围绕它构建DAL和服务层，以便您的应用可以使用它。假设您可以托管到中央服务器，如果没有野外文件的多个副本。

Answer 3

使用数据库（可能存储此配置xml文件，如果您希望保留格式）具有优势 - 您可以记录/审核对配置的更改，还可以进行备份和恢复。

基本上你的问题（我看待它的方式）混合了两件事，

1. 配置应采用何种格式（xml，.ini文件等）
2. 应存储的位置（磁盘上的平面文件，数据库中的表列）

您可以轻松地将config xml文件存储在数据库中，并提供用于编辑/显示信息的界面。

Answer 4

配置文件应该是最容易处理的事情 - 所以将它们放入文件中。这样，即使使用记事本，有人也可以在那里进行更改（如有必要）。 除非您希望您的配置驻留在某个全局服务器和所有实例中以共享它，否则数据库确实是一种过度杀伤。