Azure移動服務應用程序的體系結構

Question

我正在嘗試利用Azure移動服務將Windows通用應用程序的體系結構拼湊在一起。這是一個LOB應用程序，需要處理100-250個離線\在線表格。目前移動服務不支持嵌套的複雜對象，所以在服務方面，我已經從實體框架直接映射了大部分表格。

我的問題是我是否應該使用單獨的圖層來重新構建DTO，或者如果我應該通過服務層和視圖模型完成此操作。我主要關注的是分離責任（大團隊）和額外映射的性能開銷。

沒有聲望來添加圖像這裏是模型的鏈接。

一個例子是具有連接地址的集合Person對象。我有三個DTO對象：一個用於地址的人，另一個用於多對多的關係。如果我直接映射到視圖模型，我需要尋址服務來查找特定人員的地址。

如果我插入一個額外的「模型」圖層，我的服務將返回帶有地址集合的人員模型。這感覺有點不對......

Answer 1

正確的選擇取決於你如何在客戶端進行查詢。在你的情況下，你想直接查詢Address，所以在客戶端上有一個地址表可能很有幫助。

對DTO進行映射的原因與您所說的完全相同：Azure移動服務中的對象之間的關係沒有直接的支持。這是爲了確保客戶端和服務器之間交互的簡單模型而設計的，但是當數據模型涉及到關係時，這可能意味着更多的設計。

一般情況下，我們建議如下：

1. 如果你有1：許多關係，那裏有父母和孩子之間的明確的所有權關係，它通常是最好的映射子對象到父。這也簡化了移動客戶端創建新的子對象並與父對象關聯的情況。離線同步協議分別發送更改，因此如果對象需要爲一個原子操作，則必須將它們組合在一起。有關此示例，請參閱FieldEngineerLite sample。

2. 如果您有1：多個關係，並且直接在子對象上查詢並不重要，您可以映射爲＃1，或者爲子項創建單獨的表控制器，並使用外鍵管理映射。

3. 對於許多關係而言，它通常會增加太多的複雜性以直接暴露關係表。這裏，考慮將對象ID扁平化爲其中一個對象。在你的例子中，客戶DTO可以有一個地址ID列表，並且地址在客戶端自己的表中。

如果您選擇執行選項＃3，您的代碼需要確保將所有相關地址發送到客戶端。你可以a）映射到扁平對象，然後在客戶端解包，或者b）將子句添加到客戶端或服務器端查詢地址，以便客戶端獲得所有正確的數據。

在情況（b），你也應該確保在地址表更改Customer表上做查詢之前拉低。情況（b）很容易實現，如果有一個查詢可以完成的範圍內拉下來的地址。

例如，假設你正在建設一個顧客被分配到使用的應用程序銷售人員一個CRM應用程序。然後，您在「客戶」和「地址」上進行連接，並只獲取屬於登錄用戶所擁有客戶的地址。