考虑到你有一个WAMS服务（在我的情况下是.net后端）和客户端移动应用程序，并且你想发布v2，它包含重大的模式更改（例如将一个表拆分为两个表） ）。
我理解服务器端的暂存，但这个问题是关于客户端版本控制。如何处理更新后的移动应用程序逐渐在用户社区中推出的时间段，并且您可以在野外混合使用新旧客户端？
我想到的方法：
使用指向新服务的新网址部署v2移动应用。 PRO：简单的客户端代码CON：两个WAMS实例的费用和跨两个数据库实例的同步复杂性（单个用户可能在不同的设备上具有不同的客户端版本，并且他们在不同WAMS实例中的云数据需要保持同步，直到他们更新到处）。
使用两组或更多组数据模型类将版本感知添加到移动应用程序中 - 一组用于当前版本，另一组用于v.next。在升级服务器之前，您将推出版本感知客户端。 PRO：更简单，更便宜的服务器端管理CON：更大，更复杂的客户端代码和未更新的用户在服务器更新后被锁定。此外，在多个应用商店中的客户端应用批准时间轴上关闭服务器发布日期。
使用单个数据库和单个服务器实例，但通过巧妙地使用DTO来支持旧服务器版本和新服务器版本的混合，DTO在新模式的基础上提供旧的有线协议以及新对象。据推测，我可以在服务器上的路由路径中添加一个版本元素。 PRO：简单的客户端，没有服务器端的跨数据库同步CON：更复杂的服务器代码;如果表拆分或合并，则保持脱机同步工作变得困难（可能的解决方案：并行表与代码/脚本保持同步）
选项3是我目前最喜欢的，但有一种更好/首选的方法可以在使用.net后端服务器和支持脱机同步的多平台客户端应用程序的WAMS部署中发布重大变化吗？
答案 0 :(得分：0)
您还可以考虑使用Azure API管理服务（http://azure.microsoft.com/en-us/services/api-management/）来处理版本控制。这可能对选项1最有用。
确实没有一个简单的解决方案，如果＃3最适合您的场景，我建议您继续使用。