Mobile 使用Windows Azure移动服务飞行/版本控制客户端应用程序

假设您有一个WAMS服务（.net backend，在我的例子中）和客户端移动应用程序，并且您希望发布v2，其中包含中断模式更改（例如，将一个表拆分为两个表）

我理解服务器端的登台，但这个问题是关于客户端版本控制的。当你的更新手机应用程序逐渐在用户社区中推出，而你的新老客户混杂在一起时，你该如何应对

我想到的方法是：

使用指向新服务的新URL部署v2移动应用程序。赞成：简单的客户端代码反对：两个WAMS实例的开销和跨两个db实例同步的复杂性（单个用户可能在不同的设备上有不同的客户端版本，并且他们在不同WAMS实例中的云数据需要保持同步，直到他们在任何地方都更新）

使用两组或多组数据模型类将版本感知添加到移动应用程序中-一组用于当前版本，另一组用于v.next。在升级服务器之前，您将推出版本感知客户端。赞成：更简单、更便宜的服务器端管理反对：更大、更复杂的客户端代码和不更新的用户在服务器更新后被锁定。此外，在多个应用商店中，根据客户端应用程序批准时间表确定服务器的推出日期

使用单个数据库和单个服务器实例，但通过巧妙地使用DTO支持新旧服务器版本的混合，DTO在新模式的基础上与新对象一起呈现旧的有线协议。我可以向服务器上的路由路径添加一个version元素。赞成：简单的客户端，没有服务器端交叉数据库同步反对：更复杂的服务器代码；如果表拆分或合并，保持脱机同步工作将变得困难（可能的解决方案：并行表与代码/脚本保持同步）

---

选项3是我目前最喜欢的，但是有一个更好的/优选的方法来在WAMS部署中使用.NET后端服务器和脱机同步启用，多平台客户端应用程序

，您也可以考虑使用Azure API管理服务（）来处理版本控制。这可能对备选方案1最有用

---

确实没有一个简单的解决方案，如果#3最适合您的场景，我建议您使用它。

这对于homespun API是有意义的，但对于Azure Mobile Offline Sync schemata则没有意义，我认为它无法通过API管理服务进行版本控制。选项3是我目前最喜欢的，但我一直希望有人知道一个神奇的选项4。经过一段时间的实验和对各种devops场景的思考，选项3似乎是唯一实用的选项。DTO可以为实际的db模式提供一个shim/facade，您可以根据您希望在任何给定时间在野外支持的客户机版本控制您公开的一组版本化DTO。离线同步表使这一点更加复杂，但并非不可能得到支持。这应该是开发整个平台时首先考虑的事情（说到azure）。阅读“ToDoList”之类的文章时，一切都很好，但您描述的问题是所有移动开发问题的本质，我没有看到他们试图解决这个问题。