构建SaaS以实现数据和业务逻辑的向后兼容性

Question

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

问题是，旧的表单条目需要像第一次填写时一样工作-它需要相同的配置和业务逻辑-即使从那时起SaaS已经经历了数据架构更改和业务逻辑更改。

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

因此，我需要一种明智的方式来版本配置，业务逻辑和任何依赖。

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

对于业务逻辑，我将系统版本号与条目一起保存，例如"01“。当用户加载旧表单时，我检查条目的版本，然后从类似于“js/ JavaScript _01.js”的路径加载表单主目录。当我对业务逻辑进行非向后兼容的更改时，我将系统的版本号增加到例如"02“。然后，新表单将使用"js/main_02.js“。我也对HTML视图模板使用了这种廉价的版本控制方法，这是非常麻烦的。

这种方法是有效的，但它似乎有点脆弱或自成体系。我试图在我的业务逻辑中避免像if version==2: do this这样的条件语句。这种方法避免了这种情况，但也有它的缺点。

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

Answer 1

你可能会在这方面得到大量的“意见”，但没有真正明确的答案。

您可以以多种方式为您的配置和逻辑开发API，并将版本与提交的数据一起保存，从而需要API-Manager解决方案。

但是，您可以将整个DOM对象存储在存储数据的记录中，从而创建一个可以随意调用和重新提交的静态页面，并将视图和模型分开。