Azure 移动服务应用程序的体系结构

Question

我正在尝试为利用 Azure 移动服务的 Windows 通用应用程序拼凑一个体系结构。 这是一个 LOB 应用程序，需要处理 100-250 个离线\\在线表。 目前，移动服务不支持嵌套的复杂对象，因此在服务端，我直接从实体框架映射了大部分表。

我的问题是我是否应该使用单独的层来重构 DTO，或者我是否应该通过服务层和视图模型来完成这一切。 我主要关注的是职责隔离（大型团队）和额外映射的性能开销。

没有在此处添加图像的声誉是模型的链接。

一个例子是一个带有地址集合的 Person 对象。 我有三个 DTO 对象：一个用于人，一个用于地址，一个用于多对多关系。 如果我直接映射到视图模型，我需要一个寻址服务来查找特定人的地址。

如果我插入一个额外的“模型”层，我的服务将返回带有地址集合的人员模型。 不过感觉有点不对。。。

Answer 1

正确的选择取决于您在客户端上进行查询的方式。 在您的情况下，您想直接对 Address 进行查询，因此在客户端上拥有一个 Address 表可能会有所帮助。

映射到 DTO 的原因正如您所说：Azure 移动服务中的对象之间的关系没有直接支持。 这是为了确保客户端和服务器之间交互的简单模型而设计的，但是当数据模型确实涉及关系时，这可能意味着更多的设计。

一般来说，我们建议如下：

1. 如果您有 1:many 关系，其中父子对象之间存在明确的所有权关系，通常最好将子对象映射到父对象。 这也简化了移动客户端创建新子对象并与父对象关联的情况。 离线同步协议单独发送更改，因此如果对象需要成为一个原子操作，则必须将它们组合在一起。 有关此示例，请参阅FieldEngineerLite 示例。

2. 如果您有 1:many 关系并且直接查询子对象并不重要，您可以按照 #1 进行映射，或者为子对象创建单独的表控制器并使用外键管理映射。

3. 对于many:many关系，直接暴露关系表通常会增加太多的复杂性。 在这里，考虑将对象 ID 扁平化为其中一个对象。 在您的示例中，客户 DTO 可能有一个地址 ID 列表，这些地址位于客户端自己的表中。

如果您选择执行选项 #3，您的代码需要确保所有相关地址都发送到客户端。 您可以 a) 映射到扁平对象，然后在客户端解压缩，或者 b) 在客户端或服务器端查询地址中添加子句，以便客户端获取所有正确的数据。

在情况 (b) 中，您还应该确保在对 Customer 表进行查询之前已拉取对 Address 表的更改。 如果可以进行查询来确定要下拉的地址的范围，则情况 (b) 很容易实现。

例如，假设您正在构建一个 CRM 应用程序，其中使用该应用程序将客户分配给销售人员。 然后，您对 Customer 和 Address 进行联接，并仅获取属于登录用户拥有的客户的那些地址。