我正在尝试利用Azure移动服务将Windows通用应用程序的体系结构拼凑在一起。这是一个LOB应用程序，需要处理100-250个离线\在线表格。目前移动服务不支持嵌套的复杂对象，所以在服务方面，我已经从实体框架直接映射了大部分表格。Azure移动服务应用程序的体系结构
我的问题是我是否应该使用单独的图层来重新构建DTO，或者如果我应该通过服务层和视图模型完成此操作。我主要关注的是分离责任（大团队）和额外映射的性能开销。
没有声望来添加图像这里是模型的链接。
一个例子是具有连接地址的集合Person对象。我有三个DTO对象：一个用于地址的人，另一个用于多对多的关系。如果我直接映射到视图模型，我需要寻址服务来查找特定人员的地址。
如果我插入一个额外的“模型”图层，我的服务将返回带有地址集合的人员模型。这感觉有点不对......
正确的选择取决于你如何在客户端进行查询。在你的情况下，你想直接查询Address，所以在客户端上有一个地址表可能很有帮助。
对DTO进行映射的原因与您所说的完全相同：Azure移动服务中的对象之间的关系没有直接的支持。这是为了确保客户端和服务器之间交互的简单模型而设计的，但是当数据模型涉及到关系时，这可能意味着更多的设计。
一般情况下，我们建议如下：
如果你有1：许多关系，那里有父母和孩子之间的明确的所有权关系，它通常是最好的映射子对象到父。这也简化了移动客户端创建新的子对象并与父对象关联的情况。离线同步协议分别发送更改，因此如果对象需要为一个原子操作，则必须将它们组合在一起。有关此示例，请参阅FieldEngineerLite sample。
如果您有1：多个关系，并且直接在子对象上查询并不重要，您可以映射为＃1，或者为子项创建单独的表控制器，并使用外键管理映射。
对于许多关系而言，它通常会增加太多的复杂性以直接暴露关系表。这里，考虑将对象ID扁平化为其中一个对象。在你的例子中，客户DTO可以有一个地址ID列表，并且地址在客户端自己的表中。
如果您选择执行选项＃3，您的代码需要确保将所有相关地址发送到客户端。你可以a）映射到扁平对象，然后在客户端解包，或者b）将子句添加到客户端或服务器端查询地址，以便客户端获得所有正确的数据。
在情况（b），你也应该确保在地址表更改Customer表上做查询之前拉低。情况（b）很容易实现，如果有一个查询可以完成的范围内拉下来的地址。
例如，假设你正在建设一个顾客被分配到使用的应用程序销售人员一个CRM应用程序。然后，您在“客户”和“地址”上进行连接，并只获取属于登录用户所拥有客户的地址。
谢谢林迪，这让我感到放心，我正朝着这条正确的道路前进。正如你所说的那样，“正确的”答案将取决于对象周围的用例和孩子。但我认为这种架构将适用于所列出的场景。 – Nathan
“将子对象映射到父项”是什么意思？知道这可能有助于回答[问题]（http://stackoverflow.com/q/37174311）我刚刚发布。 – HappyNomad
这意味着您将子对象包含在父对象中。例如，如果您有一个客户和地址表，则可以将地址字段包含在客户对象中，而不是使用外键。换句话说，你使你的实体非规范化。 –
你需要做的查询，直接在（涉及到人与其他对象）的地址，或者他们总是从直接的人抬头？ –
还有一个问题：View Model和View在客户端上，对吗？ –
我希望能够做到这一点。有几种用例，例如向我展示位于x英里范围内的所有员工。在目前我通过包括在父子关系处理这个，所以我做我的查询子对象，然后根据结果集加载父母。 DTO，Model，ViewModel和View对象都位于客户端上。 – Nathan