mobile - 带有 Windows Azure 移动服务的 Flighting/Versioning 客户端应用程序

Question

考虑到您有一个 WAMS 服务(在我的例子中是 .net 后端)和客户端移动应用程序，并且您想要发布 v2，其中包含破坏性的架构更改(例如将单个表拆分为两个表).

我了解在服务器端暂存，但这个问题是关于客户端版本控制的。在您更新的移动应用程序逐渐在用户社区中推出并且您的新老客户混杂的这段时间里，您该如何应对？

我想到的方法:

1. 使用指向新服务的新 URL 部署 v2 移动应用程序。优点:简单的客户端代码 缺点:两个 WAMS 实例的开销和跨两个数据库实例同步的复杂性(单个用户可能在不同的设备上有不同的客户端版本，并且他们在不同 WAMS 实例中的云数据需要保持同步，直到它们在所有地方更新).

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

3. 使用单个数据库和单个服务器实例，但通过巧妙地使用 DTO 支持新旧服务器版本的混合，DTO 在新模式和新对象的基础上呈现旧的线路协议(protocol)。据推测，我可以将版本元素添加到服务器上的路由路径。 PRO:简单的客户端，没有服务器端跨数据库同步 CON:更复杂的服务器代码；如果表拆分或合并，保持离线同步工作变得困难(可能的解决方案:并行表与代码/脚本保持同步)

选项 3 是我目前最喜欢的，但是是否有更好/更喜欢的方法来在具有 .net 后端服务器和支持离线同步的多平台客户端应用程序的 WAMS 部署中阻止重大更改？

Answer 1

您还可以考虑使用 Azure API 管理服务 (http://azure.microsoft.com/en-us/services/api-management/) 来处理版本控制。这可能对选项 1 最有用。

确实没有简单的解决方案，如果 #3 最适合您的情况，我建议您采用它。