database - 存储在数据中的流程或逻辑是好的还是坏的做法？

Question

这是我试图弄清楚的建筑理论问题。

在我的项目中有几个页面，每个页面都会触发一个事件(或多个事件)这个事件可能不会引起什么 react ——因为页面之间的正常流程是正常的

我正在研究一个理论，我想使用虚幻引擎创建页面之间的流程逻辑来创建 BluePrints或者还有一个名为 Blueprints.NET 的虚拟图书馆

所以在我的项目中它看起来像这样:

send、show 是逻辑实体的入口，onClick、onContinue 等是每个流实体框的退出事件。

在我的架构中，我想将页面之间的流连接存储在数据库中数据表示例:

EntityID   Event       NextEntityID   EntryID   Parameters
=======================================================
Intro      onClick     Login          Show      NULL
Login      onContinue  Autho          Send      {User,Pass}
Login      onCancel    Login          Show      NULL

我知道将逻辑存储在数据库中会带来一些缺点(例如丢失的数据和虚假数据)，这些缺点可以解决

有一件事很重要，我有几十个行为相同但流程不同的项目。所以不是为每个项目创建一个逻辑库(用 C# 或 Java 或任何其他语言)。我会创建一个框架，可以使用相同的术语和 entity boxes 但每次都不同的流程。无需为每个项目编译逻辑库

这里的主要问题是您会这样做吗？你认为这是一种不好的做法吗？ - 如果是，为什么？ - 请记住这是一个工作理论

Answer 1

一种避免重建应用程序的有趣方法。

我认为有趣的问题是:

• 哪些参数是允许的并且可以传递给实体？你如何确保实体接口(interface)的稳定性？
• 您如何确保处理复杂数据类型的可能性？
• 如何处理实体和配置的不同软件版本？
• 会发生哪些错误和异常？如何应对？
• 允许哪种流程？ (例如，实体“目录页”可以调用“介绍页”吗？)

总而言之，您已将应用程序拆分为功能逻辑和流程逻辑。由于一个在代码中，另一个在数据库或文件中，我认为最大的问题是维护。一方面要确保流配置正确，另一方面要确保您不会损坏实体之间的接口(interface)。缺点是只能在运行时检测到错误。

但也许对于简单的应用程序它可以工作:)