我有一个SaaS平台，用户填写表格，输入表格的数据会保存到数据库中。表单UI具有大量配置（源自数据库，但最终使用JavaScript）和业务逻辑（使用JavaScript）。在填写并保存表单后，用户可以随时返回并进行编辑。
皱纹是旧表单条目需要像第一次填写时一样 - 它需要相同的配置和业务逻辑 - 即使SaaS已经完成了数据模式更改并且更改了业务逻辑然后。
要确认，用户填写的新表单当然会使用新的/当前的数据模式和业务逻辑。但是之前的形式需要像创建它们时那样表现。
因此，我需要一种合理的方式来配置版本配置，业务逻辑和任何依赖项。
我提出的最好的方法是，当用户保存其条目时，将表单的配置与条目一起保存为JSON。当用户返回编辑旧条目时，我不会从当前数据库模式加载配置，而只是转储随条目保存的JSON配置。
对于业务逻辑，我将系统版本号与条目一起保存，例如＆＃34; 01＆＃34;。当用户加载旧表单时，我检查条目的版本，然后从类似＆＃34; js / main_01.js＆＃34;的路径加载表单JavaScript。当我对业务逻辑进行非向后兼容的更改时，我会将系统的版本号增加到例如＆＃34; 02＆＃34;。然后新表格将使用＆＃34; js / main_02.js＆＃34;。我也使用这种廉价的版本控制方法来处理HTML视图模板。
这种方法有效，但似乎有点脆弱或本土。我试图在if version==2: do this这样的业务逻辑中避免条件限制。这种方法避免了这种情况，但也有它的缺点。
我不认为堆栈真的对这个convo很重要，但为了以防万一，我使用的是django / mysql。
答案 0 :(得分：1)
你可能会得到大量的意见＆＃34;对此，并没有真正明确的答案。
您可以通过可能的方式为配置和逻辑开发API，并使用提交的数据保存版本，从而需要API-Manager解决方案。
但是，您可以将整个DOM对象存储在存储数据的记录中，从而创建一个静态页面，可以随意调用和重新提交，并在视图和模型之间分离。