在数据库中存储UI逻辑是否是一种好的实践？

Question

在数据库中存储UI逻辑是否是一种好的实践？

4

最近我开始在这家公司工作，他们向我展示了公司项目中使用的“框架”。主要目标是将所有工作都从数据库中完成，因为这样以后就可以更改数据库而不需要修改代码，这样更为简单。它看起来像下面这样：

|id |component_id |default  |read_only|visible|form_id|
|---|-------------|---------|---------|-------|-------|
|1  |2            |now() + 4|false    |true   |3      |
|2  |1            |null     |false    |true   |4      |
|3  |5            |null     |true     |true   |1      |

component_id 是用于访问组件表，该表定义了诸如日期选择器、输入框、下拉框等各种字段，而 form_id 则用于访问另一个表格，其中包含应用程序中的不同表单，例如注册、登录、添加订单等等。

这只是一个过度简化，因为他们还有更多列和更多表格，仅使用此表就可以在 UI 中显示数据，并且具有触发不同操作的操作。

我的问题是，这是一种好的实践吗？我是说，代码看起来非常复杂，只是为了允许这样做，而且数据库混乱，有很多不同的表格仅存储逻辑。或者这是人们经常使用的东西，因为我之前没有遇到过。

我们在前端使用 Dart/Flutter，我喜欢强类型语言，但这会导致我们需要猜测数据库中的值是什么，因此失去了强类型的优势，并且必须使用 switch 语句检查要呈现哪个组件并应用所有其他值的巨大文件。

我认为只需在需要时编写代码会更容易，因为它更简单，更易于查看，而不是试图理解所有这些疯狂的内容... 我是对的吗？

- Miguel Bogota

1

你说得对，这真是可怕。同时也可能意味着人们不断地在生产环境中操纵数据，这本身就很令人担忧。 - Nathan Hughes

谢谢，是的。那就是我在想的。 - Miguel Bogota

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- gmiley · Accepted Answer

这是过度设计的典型例子。该设计存在许多问题，其中一个主要问题是引入了大量的风险。它不仅使开发成为一场噩梦，还允许开发人员绕过任何风险控制，例如代码扫描。它还引入了可能的攻击向量，因为它依赖于外部可变源来实现运行时行为。

来自数据库的数据应该仅仅只是数据，而业务层应该是一组稳定的逻辑指令，用来操作这些数据。越少交叉干扰越好。

这种设计还会导致版本管理数据集与代码库一样复杂。然后你需要确保它们能够同步。

不幸的是，你可能在工作的地方仍然有这个噩梦的原始架构师，或者你的开发团队已经习惯了这样松散的风险控制，将其转换为适当的设计就像拔牙一样困难。如果你打算最终将他们引导到正确的方向，你最好是将问题提出作为风险与回报的问题，并准备好提出解决方案。