为数据和业务逻辑方面的向后兼容性设计SaaS

Question

我有一个SaaS平台，用户填写表单并将表单中的数据保存到数据库中。表单UI有大量的配置(来自DB，但最终出现在JavaScript中)和业务逻辑(在JavaScript中)。填写并保存表单后，用户可以随时返回并编辑表单。

缺点是，旧表单条目需要表现得像第一次填写时那样--它需要相同的配置和业务逻辑--即使SaaS从那时起就经历了数据模式更改和业务逻辑更改。

要确认，当然，用户填写的新表单将使用新的/当前的数据模式和业务逻辑。但是以前的表单需要像它们创建时那样运行。

因此，我需要一种合理的方法来实现版本配置、业务逻辑和任何依赖项。

我想出的最好方法是，当用户保存他们的条目时，将表单的配置与条目一起保存为JSON。当用户回到编辑旧条目时，我不会从当前数据库模式加载配置，而只是转储与条目一起保存的JSON配置。

对于业务逻辑，我保存一个系统版本号和条目，例如"01“。当用户加载旧表单时，我检查表单的版本，然后从"js/main_01.js“这样的路径加载表单JavaScript。当我对业务逻辑进行不向后兼容的更改时，我会将系统的版本号增加到"02“。新表单将使用"js/main_02.js“。我还为HTML视图模板使用了这种廉价的版本控制方法，该模板变得越来越毛茸茸。

这种方法有效，但它似乎有点脆弱或土生土长。在我的业务逻辑中，我试图避免使用像if version==2: do this这样的条件。这种方法避免了这一点，但也有它的缺点。

我不认为堆栈对这个会议很重要，但为了以防万一，我使用django/mysql。

Answer 1

假设您已经处于这种情况下：

1. 将表单配置存储在DB中并引用版本号，而不是一次又一次地将其序列化到Json。
2. 不要使用条件，只有完全独立的html/js对和后端点。如果要将表单显示在单个url下面，则可能需要进行一些内部重写。

您正面临遗留/长寿/非平凡系统的现实。我们的想法是从一开始就设计变化。我几乎可以肯定你能把这个改造成理智。将表单划分为逻辑模块；每个模块将注入所需的标记、js ( js中的业务逻辑是另一个主题)和后端处理依赖项；然后通过一些直接的配置混合和匹配。如果您没有时间返回并重构，请从版本N+1开始。