我应该使用配置文件还是数据库来存储业务规则？

我最近在阅读《实用程序员》，其中指出：

细节弄乱了我们原始的代码，尤其是如果它们经常更改。每次我们必须修改代码以适应业务逻辑，法律或管理层的个人喜好时，都会冒着破坏系统的风险—引入新的错误。

亨特，安德鲁；托马斯·戴维（1999-10-20）。实用程序员：从《旅人》到《大师》（Kindle位置2651-2653）。培生教育（美国）。Kindle版。

我目前正在编程一个具有某些模型的Web应用程序，这些模型的属性只能来自一组值，例如（由于Web应用程序数据是机密的，因此不是实际示例）：

light-> type =球体/立方体/圆柱体

光源类型只能是上述三个值，但根据TPP，我应始终进行编码，好像它们可以更改并将其值放置在配置文件中一样。由于在整个应用程序中都发生过几次此类事件，因此我的问题是：

我是否应该在以下位置存储类似的值：

• 配置文件：
  'light-types' => array(sphere, cube, cylinder),
'other-type' => value,
'etc' => etc-value

• 数据库中的一个表，每个配置项一行

• 一个数据库，其中每个配置项都有一个表（例如table light_types：； columns ：id、name）

• 其他方式？

非常感谢您提供的任何帮助/专业知识。

在我从事的大多数项目中，都会出现相同的问题。通常，我这样做：

1. 如果一组可能的值不太可能在短期内更改，那么我将在数据库中的代码和可枚举字段中使用类/接口常量或枚举。示例：博客条目的发布状态：“未发布”，“审核中”，“已发布”等
2. 值可能会更改，但更改不会影响程序逻辑-配置文件。示例：“您如何找到我们的网站？”列表 在线购买表单中的下拉列表的选项。
3. 值可能会经常更改和/或打算由非开发人员编辑，但这些更改不会影响逻辑-数据库或至少具有一些用户友好的编辑界面的键值存储。
4. 更改值将影响逻辑-可能需要重新设计系统（通常为true）或需要一些业务规则引擎。到目前为止，我所见过的最困难的案例是我的同事从事的心理测验构造函数。每种类型的测试都有自己的评分系统，可以从简单的添加到具有正负值的多个特征量表，甚至可以人工评估答案。在对该项目进行了一些讨论之后，我们最终使用Lua作为脚本引擎，这与非开发人员创建新测试的能力完全冲突（即使Lua是一种相对简单的语言，您也不应指望非程序员会学到的）。

关于TPP的报价。我认为原始代码是正确的，但在现实生活中，最好从简单开始（KISS原则），然后在确实需要时添加功能（YAGNI）。

如果您的数据将在数据库中，我建议在同一数据库中有一个“ light_types”表。这使您能够使用外键强制执行一个约束，即light-> type只能是这些值之一，因此即使代码混乱，数据库中的数据也将始终有效。

如果数据不会存储在数据库中，那么仅为一堆枚举创建一个数据并不会带来很多好处。如果您确实要避免对值进行硬编码，那么我可能会建议一个配置文件。

（不过，我警告不要避免避免硬编码。在任何非平凡的系统中，都会有关于业务规则和要求的假设，无论作者是否意识到。即使您设法避免所有假设并使用绝对代码对所有内容进行软编码，您基本上只会得到一个“规则引擎”，一种系统内系统和/或元语言，而您在元语言中还有很多东西实施规则您没有节省任何工作或获得任何灵活性；您只需要构建和/或学习另一种语言。

现在，如果你想找到并使用现有的规则引擎，这可能会为您节省一些工作（有回答的在哪里存储枚举的问题一起）。但是，构建自己的系统只会使工作量加倍，并且不可避免地会为您提供由真正不知道如何制作像样的规则引擎的人构建的半资产评估系统。）

通常，应将数据库用于数据，将配置文件用于配置。（顾名思义:)）。将配置保留在数据库中会严重分散关注点，只有在有充分用例证明其合理性时，才应这样做。

在决定使用多少配置时，要取得平衡。您应该像对待代码一样对待配置文件。保持简洁。应用程序很容易遭受配置膨胀的困扰，最终您会得到一个充满魔术字符串的巨大xml文件。

在您描述的情况下，使用配置元素定义要使用的css文件是合理的。（然后，如果需求发生变化，则可以对其进行更改）。在配置文件中配置每个元素的样式可能会过大