ViewModel類設計 - 它應該在服務器端還是客戶端？

Question

在我的應用程序中，我有一個View，它需要來自多個服務器端數據模型的數據。

我們有兩種選擇。

1. 喊單WebSevice一次，並從服務器端獲取視圖模型類的對象，並將其綁定到視圖。

2. 調用多個WebServices並獲取不同的服務器端模型類，並在客戶端創建一個新的View Model Class並將其綁定到視圖。

這兩個選項中最好的方法是什麼？請指教。

Answer 1

如果有疑問，請考慮您的用戶體驗。

從用戶的角度來看，最令人沮喪的事情之一是等待應用程序在他們按下某些內容後做出響應。

每當您的應用程序向您的服務器發出請求時，用戶都會遇到延遲 - 每增加一個請求都會延長該延遲的時間。大多數典型的用戶對這類事情的容忍度很低，然後他們會感到惱火，並將您的應用視爲「緩慢」。

爲了儘量減少內容加載所需的時間，請將您的客戶端和您的服務器API之間的呼叫數量保持在絕對最小值 - 一般來說，呼叫越少越好。這嚴重傾向於'單一請求，單一ViewModel'的方法。

也要注意你的ViewModel有效載荷的大小;當大部分數據永遠不會被看到或使用時，不要僅僅向用戶返回一個巨大的數據轉儲 - 這不僅會浪費帶寬並使事情變得更慢，而且還意味着客戶將會做額外的不必要的工作。

這對您的服務器也有好處;如果您的服務器需要滿足更少的請求，那麼在擴展應用程序以應對更多用戶時，您將不再需要做更多的工作。

最後，考慮一個簡單的輕量級「啞」客戶端，它只負責演示和用戶交互，而不是負載較重的客戶端應用程序。

• 通過使您的服務器負責生成一個ViewModel，做所有的辛勤工作，你能避免您的客戶端上的商業邏輯;因此保持業務層和應用層之間的清晰分離。另一方面，如果您需要多個服務器API調用，那麼您的客戶端可能需要更多的複雜性來構建View Model，這可能會導致應用程序與業務層之間的界限模糊不清。

如果你最終建立其調用相同的服務器上有多個不同的客戶端應用程序，你可能會發現自己需要的應用程序之間重複使用的業務邏輯;重新使用服務器上已存在的業務邏輯會更容易 - 特別是如果客戶端應用程序使用不同的技術（例如Web客戶端和移動應用程序）。