Azure 移动服务应用程序的体系结构 [英] Architecture of Azure Mobile Services Application
问题描述
我正在尝试为利用 Azure 移动服务的 Windows 通用应用程序拼凑一个体系结构.这是一个 LOB 应用程序，需要处理 100-250 个离线\在线表.目前，移动服务不支持嵌套的复杂对象，因此在服务端，我直接从实体框架映射了大部分表.
I'm trying to piece together an architecture for a Windows Universal App leveraging Azure Mobile Services. It's a LOB app and will need to handle 100-250 offline\online tables. Currently Mobile Services doesn't support nested complex objects so on the service side I've mapped most of my tables straight through from entity framework.
我的问题是我是否应该使用单独的层来重构 DTO，或者我是否应该通过服务层和视图模型来完成这一切.我主要关注的是职责隔离(大型团队)和额外映射的性能开销.
The question I have is whether I should use a separate layer to reconstitute the DTO's or if i should be doing this all through the service layer and the view model. My main concerns are isolation of responsibility (large team) and the performance overhead from the additional mapping.
没有添加图片的声誉，这里是模型的链接.
Didn't have the reputation to add an image here's the link to the model.
一个例子是一个带有地址集合的 Person 对象.我有三个 DTO 对象:一个用于人，一个用于地址，一个用于多对多关系.如果我直接映射到视图模型，我需要一个寻址服务来查找特定人员的地址.
An example would be a Person object with a collection of addresses attached. I have three DTO objects: one for the person one for the address and one for the many to many relationship. If I'm mapping straight through to the view model i'd need an addressing service to lookup the address for a specific person.
如果我插入一个额外的模型"层，我的服务将返回带有地址集合的人员模型.不过感觉有点不对……
If i insert an extra "Model" layer my service returns the Person Model with a Collection of address on it. It feels a bit wrong though...
推荐答案
正确的选择取决于您在客户端上进行查询的方式.在您的情况下，您想直接对 Address 进行查询，因此在客户端上有一个 Address 表可能会有所帮助.
The right choice depends on how you are doing querying on the client. In your case, you want to do querying on Address directly, so it is probably helpful to have an Address table on the client.
映射到 DTO 的原因正如您所说:Azure 移动服务中的对象之间的关系没有直接支持.这是为了确保客户端和服务器之间交互的简单模型而设计的，但当数据模型确实涉及关系时，这可能意味着更多的设计.
The reason for doing the mapping to DTOs is exactly as you said: there is no direct support for relationships between objects in Azure Mobile Services. This is by design to ensure a simple model for interacting between client and server, but it can mean more design when the data model does involve relationships.
总的来说，我们建议如下:
In general, we advise the following:
如果您有 1:many 关系，其中父子对象之间存在明确的所有权关系，通常最好将子对象映射到父对象.这也简化了移动客户端创建新子对象并与父对象关联的情况.离线同步协议单独发送更改，因此如果对象需要成为一个原子操作，则必须将它们组合在一起.有关此示例，请参阅 FieldEngineerLite 示例.
如果您有 1:many 关系并且直接查询子对象并不重要，您可以按照 #1 进行映射，或者为子对象创建单独的表控制器并使用外键管理映射.
If you have 1:many relationships and it's not important to query on the child objects directly, you can either map as in #1, or create separate table controllers for the children and manage the mapping with foreign keys.
对于many:many关系，直接暴露关系表通常会增加太多的复杂性.在这里，考虑将对象 ID 扁平化为其中一个对象.在您的示例中，客户 DTO 可能有一个地址 ID 列表，这些地址位于客户端自己的表中.
For many:many relationships, it usually adds too much complexity to expose the relationship table directly. Here, consider flattening the object IDs into one of the objects. In your example, the Customer DTO could have a list of Address IDs, and the addresses are in their own table on the client.
如果您选择执行选项 #3，您的代码需要确保所有相关地址都发送到客户端.您可以 a) 映射到扁平对象，然后在客户端解包，或者 b) 向客户端或服务器端地址查询添加子句，以便客户端获取所有正确的数据.
If you choose to do option #3, your code needs to make sure that all the relevant addresses are sent down to the client. You could either a) map to a flattened object and then unpack on the client side, or b) add clauses to either the client or server side query for addresses so that the client gets all the right data.
在情况 (b) 中，您还应确保在对 Customer 表执行查询之前已拉取对 Address 表的更改.如果可以进行查询来确定要下拉的地址的范围，则情况 (b) 很容易实现.
In case (b), you should also ensure that changes to the Address table are pulled down before doing queries on the Customer table. Case (b) is easy to implement if there is a query that can be done to scope what addresses to pull down.
例如，假设您正在构建一个 CRM 应用程序，其中使用该应用程序将客户分配给销售人员.然后，您对 Customer 和 Address 进行联接，并仅获取属于已登录用户拥有的客户的那些地址.
For instance, suppose you are building a CRM app where a customer is assigned to the salesperson using the app. Then, you do a join on Customer and Address and get only those Addresses that belong to a customer owned by the logged in user.
这篇关于Azure 移动服务应用程序的体系结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
