19、Web API、客户端集成与移动应用开发

Web API、客户端集成与移动应用开发

1. Web API 与客户端集成

在开发过程中， OnOrderUpdated 和 OnBatchUpdated 方法会调用事件来通知更新。同时，我们添加了两个方法，通过 IHubProxy.Invoke<T> 方法调用网站中创建的集线器方法：

public async Task<bool> UpdateOrder(Order order)
{
    // Invoke updateOrder method on hub
    await this._proxy.Invoke<Order>("updateOrder",  
      order).ContinueWith(task =>
    {
        return !task.IsFaulted;
    });
    return false;
}
public async Task<bool> UpdateBatch(Batch batch)
{
    // Invoke updateBatch method on hub
    await this._proxy.Invoke<Batch>("updateBatch",  
      batch).ContinueWith(task =>
    {
        return !task.IsFaulted;
    });
    return false;
}

这个服务实现了 IManagementService 接口，并在 ViewModelLocator 类中注册，以便注入到视图模型中：

SimpleIoc.Default.Register<IManagementService, ManagementService>();

2. 应用程序测试

本地测试应用程序时，需要同时启动 Web API 项目和 WPF 客户端应用程序。操作步骤如下：
1. 在解决方案属性对话框的“启动项目”部分，选中“多个启动项目”。
2. 选择这两个应用程序。
3. 点击“确定”。

测试在云端运行的服务时，需要将服务部署到云端，然后更改客户端 app.config 文件中的设置。调试客户端与 Azure 服务时，确保只运行客户端应用程序；调试 Azure Web API 则需遵循特定的调试流程。

3. 相关问题解答

问题	答案
为什么在使用 SQL Azure 数据库时 Web 服务特别重要？	SQL Azure 仅支持 SQL 身份验证，客户端应用程序需要访问登录详细信息，这可能带来安全风险。
在负载均衡的网站中实现 SignalR 有什么问题？	SignalR 客户端与单个集线器保持连接，这意味着它们不会向其他集线器实例发送数据或从其他集线器实例接收数据。
如何解决上述问题？	实现一个背板系统，如 Azure 服务总线，以实时更新集线器。
如何在控制器中强制执行授权？	在控制器或单个操作级别使用 Authorize 属性。
在不编写任何代码的情况下，有哪些技术可用于测试 Web API 服务？	如果暂时移除 Authorize 属性，可以使用浏览器进行 HTTP GET 请求，或使用 Fiddler 或 cURL 等工具进行其他请求。
SignalR 集线器的 URL 是什么？	api/signalr
如何在 SignalR 集线器中强制执行授权？	使用相同的 Authorize 属性。
发布期间启用组织身份验证设置能实现什么？	将为新站点预配一个 AD 应用程序，并使用新的 ida:Audience ID 更新站点的 Web.config 文件。
为什么必须修改 Web API AD 应用程序清单的 appPermissions 部分？	需要授予客户端应用程序访问权限。
在客户端应用程序的配置中， ida:Audience 和 ida:ClientID 设置是什么？	ida:Audience ID 是目标应用程序（即 Web API）的 ID， ida:ClientID 是客户端应用程序的 ID。
如果用户的身份验证令牌已过期，如何在用户不再次登录的情况下对其进行身份验证？	使用 RefreshToken 令牌和 AuthenticationContext.AcquireTokenByRefreshToken 方法刷新令牌，无需再次登录。
客户端如何调用 SignalR 集线器方法，如何判断是否成功？	使用 IHubProxy.Invoke<T> 方法调用集线器方法，然后使用 .ContinueWith 延续方法，该方法提供一个带有 IsFaulted 标志的任务对象。

4. 移动应用集成与 Azure 移动服务

我们将为销售业务部门构建 Windows Phone 应用程序和 Azure 移动服务，让客户查看订单、接收订单状态更改和新产品添加的通知；为供应业务部门创建 Windows Store 应用程序和 Azure 移动服务，方便仓库员工在平板电脑上查看待发货订单。销售系统架构如下：

graph LR
    A[Customer Website] --> B[Mobile Service]
    C[Admin Website] --> B
    B --> D[Order Topic]
    D --> E[Database]
    D --> F[Order Processor]
    F --> G[Notification Hub]
    G --> H[PNS]
    H --> I[Phone App]
    B --> I
    B --> J[New Orders]
    B --> K[Order Status]
    B --> L[Orders]
    I --> M[Push Notifications]
    I --> N[Register “News”, “Handle”]

5. Azure 移动服务介绍

Azure 移动服务是一个出色的平台，可让移动开发人员快速创建后端服务，用于存储数据、创建自定义 API 以与自己的数据或外部资源进行交互。它具有以下特点：
- 支持推送通知，为所有主要平台提供推送通知服务 API。
- 具有细粒度的授权控制，允许将不同的授权级别应用于各个服务方法，并支持自定义授权提供程序。
- 与其他服务类型相比，具有灵活的授权模型、通知集成以及优秀的 SDK。

Azure 移动服务提供四种授权级别：
|授权级别|描述|
|----|----|
|Anonymous/Everyone|未经过身份验证，任何拥有服务 URL 的人都可以访问。|
|Application/Anybody with the application key|所有服务都有一个应用程序密钥，请求需要包含 X-ZUMO-APPLICATION 标头。|
|User/Only authenticated users|仅允许通过允许的身份验证提供程序（如 Twitter、Facebook、Google、Microsoft 和 Azure AD）进行身份验证的用户访问，请求需要包含 X-ZUMO-AUTH 标头。|
|Admin/Only scripts and admins|这是最高授权级别，使用主密钥覆盖所有其他级别，请求需要包含 X-ZUMO-MASTER 标头。主密钥不应与客户端应用程序一起分发，因为它们允许无限制的服务访问，可能导致服务被滥用。|

6. 创建客户 Azure 移动服务

要创建一个与销售系统中现有客户匹配的移动服务，让客户查看订单并接收通知。可以使用 Windows Azure 移动服务自定义控制器来检索数据，或者使用 AutoMapper 等工具将数据从自己的数据架构重新映射到实现 ITableData 接口的数据服务。在本应用程序中，由于与数据库的交互较少，仅检索订单，因此选择使用自定义控制器。

Web API 后端服务中的推送通知只能使用通知中心，不能直接与推送通知服务（PNS）交互。我们将使用应用程序中创建的唯一推送句柄作为标签，当发送订单更新时，使用用户的唯一句柄进行标记，只有该用户会收到通知；发送产品新闻时，使用新闻标签，所有用户都会订阅。

7. 创建移动服务项目

如果使用 Visual Studio 的高级版本，可以将移动服务添加到现有的销售解决方案中；如果是 Express 用户，则需要切换到 Visual Studio Express for Windows 并添加其他解决方案使用的现有模型项目。创建项目的步骤如下：
1. 在解决方案资源管理器窗口中，右键单击解决方案根目录。
2. 选择“添加”|“新项目”。
3. 为项目添加名称，然后点击“确定”。
4. 在接下来的对话框中，选择 Windows Azure 移动服务模板，然后点击“确定”创建服务并查看示例代码。

8. 探索移动服务示例项目

移动服务项目的结构与 MVC 项目和 Web API 项目类似。它包含一个 App_Start 文件夹，其中的 WebApiConfig 类负责初始化和配置应用程序；一个 Controllers 文件夹，其中的 TodoItemController 示例类是一种特殊类型的 API 控制器，与 EntityData 类型的模型紧密绑定。 ITableData 接口定义如下：

public interface ITableData
{
    [JsonProperty(PropertyName = "__createdAt")]
    DateTimeOffset? CreatedAt { get; set; }
    [JsonProperty(PropertyName = "__deleted")]
    bool Deleted { get; set; }
    string Id { get; set; }
    [JsonProperty(PropertyName = "__updatedAt")]
    DateTimeOffset? UpdatedAt { get; set; }
    [JsonProperty(PropertyName = "__version")]
    [SuppressMessage("Microsoft.Performance", 
    byte[] Version { get; set; }
}

项目使用 Entity Framework Code First Migrations 来构建数据库。 TodoItemController 是一个 TodoItem 类型的表控制器，可通过右键单击 Controllers 文件夹，选择“添加”|“控制器”，然后从“添加基架”对话框中选择“Windows Azure 移动服务表控制器”来创建。

9. 清理项目

由于项目包含大量演示代码和 EF 配置，在开始开发之前需要清理这些内容。具体操作如下：
- 删除以下演示文件：
- Controllers/TodoItemController.cs
- DataObjects 文件夹（因为已经有一个包含所有数据实体的模型项目）
- ScheduledJobs/SampleJob.cs
- 进行以下代码修改：
- 从 CustomerMobileServicesContext.cs 和 App_Start/WebApiConfig.cs 中删除 using CustomerMobileService.DataObjects; 行。
- 从 CustomerMobileServicesContext.cs 中删除以下代码块：

public DbSet<TodoItem> TodoItems { get; set; }
protected override void OnModelCreating(DbModelBuilder  
  modelBuilder)
{
    string schema =  
      ServiceSettingsDictionary.GetSchemaName();
    if (!string.IsNullOrEmpty(schema))
    {
        modelBuilder.HasDefaultSchema(schema);
    }

通过以上步骤，我们完成了 Web API 与客户端集成以及移动应用开发的相关工作，为应用程序的进一步开发和部署奠定了基础。

Web API、客户端集成与移动应用开发

10. 示例数据实体

DataObjects 文件夹包含一个 TodoItem 类，它定义了一些属性，同时会继承 EntityData 基类所强制的 ITableData 接口的所有属性，以便能与表控制器一起使用。创建 EntityData 类没有向导，只需正常添加一个类并手动实现 EntityData 基类即可。

11. 示例定时作业

定时作业通过 ScheduledJob 基类实现 IScheduledJob 接口。该接口强制要求实现一个名为 ExecuteAsync 的任务，该任务不返回值：

public interface IScheduledJob
{
    Task ExecuteAsync(ScheduledJobDescriptor  
      scheduledJobDescriptor, CancellationToken cancellationToken);
}

该任务可通过 ScheduledJob 基类中的 Services 属性访问移动服务资源。定时作业可通过简单的 HTTP POST 请求（携带正确的身份验证标头，本示例中无身份验证）调用，它们从门户中移动服务工作区的“SCHEDULER”选项卡进行调度。创建 ScheduledJob 类没有向导，只需正常添加一个类并手动实现 ScheduledJob 基类。

12. 移动服务 DbContext

Models 文件夹包含项目的 DbContext ，它负责提供对 DataSet 属性的访问，并使用 AttributeToColumnAnnotationConvention 在实体上进行属性注释来映射实体。

13. WebApiConfig

WebApiConfig.Register 方法在应用程序启动时由 Global.asax 调用，负责为移动服务专门配置 Web API 服务，并使用实现 DropCreateDatabaseIfModelChanges 的 DbContext 初始化器来初始化数据库（需注意，每次模型更改时它会删除数据库：http://msdn.microsoft.com/en-us/library/gg696323(v=vs.113).aspx），且有一个 Seed 方法将一些 TodoItems 插入到 TodoItems 表中。

14. 供应系统架构

在供应系统中，添加了另一个订单处理器云服务，它将订单地址添加到供应表存储中，并将条形码地址标签添加到 blob 存储中，供移动服务使用。供应系统架构如下：

graph LR
    A[Order Topic] --> B[Order Table]
    A --> C[Barcode BLOBs]
    A --> D[Order Processor]
    D --> E[Mobile Service]
    E --> F[Order Updates]
    E --> G[Dispatched]

15. 身份验证实现

对于销售客户手机应用程序，我们将使用 Twitter 身份提供者实现用户级身份验证，因为客户网站已经使用了该身份验证方式，客户可以使用相同的凭据登录。对于供应 Windows 应用商店应用程序，我们将使用 Azure AD 实现用户级身份验证，因为这是一个内部系统，且我们在所有其他内部系统中都使用了 AD。对于管理网站和订单处理器，我们将使用管理员授权级别，因为这些是后端服务，我们不希望其他任何东西使用这些服务。

16. 后端平台选择

Node.js 是最初的后端平台，允许开发人员在门户中使用出色的脚本编辑器编写脚本来修改表行为、创建自定义 API 和计划任务。可以使用 Git（http://git-scm.com/）将脚本拉到本地，以便在开发者首选的 IDE 中进行备份和本地开发。Node.js 脚本可以使用 NPM 包，这些包类似于 .NET 开发人员使用的 NuGet 包，允许使用第三方库。

2014 年初引入的 Web API 后端提供了大致相同的功能，但门户中没有编辑器（Node.js 可以在运行时解释脚本，而 Web API .NET 需要先编译代码）。对于 .NET 开发人员来说，Web API 后端是一个明显的选择，因为它最为熟悉。在我们的案例研究中，它还允许我们重用数据模型，提供更统一的开发体验。

17. 总结

我们在开发过程中涵盖了多个重要方面。通过 Web API 与客户端集成，实现了生产管理 Windows 客户端应用程序对生产数据库数据的访问，以及使用 SignalR 集线器处理订单和批次更改，确保所有客户端保持更新并向服务总线主题发送消息。同时，我们还探索了使用 Azure AD 提供统一的身份验证系统。

在移动应用开发方面，我们为销售和供应业务部门分别构建了 Windows Phone 和 Windows Store 应用程序，并使用 Azure 移动服务作为后端。Azure 移动服务提供了数据存储、自定义 API、推送通知和细粒度授权控制等功能，为移动应用的开发提供了强大的支持。

通过合理选择后端平台、实现身份验证和清理项目等操作，我们为应用程序的开发和部署做好了充分准备。未来，我们可以在此基础上进一步完善应用程序的功能，提升用户体验。

18. 待解决问题思考

虽然我们已经完成了很多工作，但仍有一些问题值得进一步思考和解决：
- 如何优化 Web API 和客户端之间的通信，以提高性能和响应速度？
- 在使用 Azure 移动服务时，如何更好地管理授权级别，确保数据的安全性和隐私性？
- 对于推送通知，如何提高通知的送达率和用户参与度？

通过不断探索和实践，我们可以逐步解决这些问题，使应用程序更加完善和稳定。