【发布时间】：2014-12-04 08:07:58
【问题描述】：
假设您有一个 WAMS 服务（在我的例子中是 .net 后端）和客户端移动应用程序，并且您想要发布 v2，其中包含破坏性架构更改（例如，将单个表拆分为两个表)。
我了解服务器端的暂存，但这个问题是关于客户端版本控制的。当您的更新后的移动应用程序逐渐在用户社区中推出并且您在野外有新老客户混合时，如何处理？
我想到的方法：
使用指向新服务的新 URL 部署 v2 移动应用程序。优点：简单的客户端代码 缺点：两个 WAMS 实例的费用和两个数据库实例之间同步的复杂性（单个用户可能在不同的设备上拥有不同的客户端版本，并且他们在不同 WAMS 实例中的云数据需要保持同步，直到它们到处更新）。
使用两组或多组数据模型类将版本感知添加到移动应用程序中 - 一组用于当前版本，一组用于 v.next。在升级服务器之前推出版本感知客户端。优点：更简单、更便宜的服务器端管理 缺点：更大、更复杂的客户端代码和不更新的用户在服务器更新后被锁定。此外，根据多个应用商店中的客户端应用批准时间线来控制服务器推出日期。
使用单个数据库和单个服务器实例，但通过巧妙地使用 DTO 来支持新旧服务器版本的混合，该 DTO 在新模式之上与新对象一起呈现旧的有线协议。据推测，我可以在服务器上的路由路径中添加一个版本元素。 PRO：简单的客户端，没有服务器端跨数据库同步 CON：更复杂的服务器代码；如果表拆分或合并，保持离线同步工作变得困难（可能的解决方案：并行表与代码/脚本保持同步）
选项 3 是我目前最喜欢的，但在 WAMS 部署中是否有更好/首选的方式来进行重大更改，其中包含 .net 后端服务器和支持离线同步的多平台客户端应用程序？
【问题讨论】：
-
经过相当多的实验和思考各种 devops 场景后，选项 3 似乎确实是唯一实用的选项。 DTO 可以为实际的 db 模式提供 shim/facade，并且您可以在任何给定时间根据您希望在野外支持的客户端版本来控制您公开的版本化 DTO 集。离线同步表使这更复杂，但并非不可能支持。
-
这应该是整个平台开发时首先想到的（说到天蓝）。阅读“ToDoList”等内容时一切都很好，但是您描述的问题是所有移动开发问题的本质，我还没有看到他们试图解决这个问题。
标签： mobile azure-mobile-services