數據傳輸對象的數據能否與UI需求相匹配

數據傳輸對象包含來自發送給客戶端的多個業務對象的數據。數據傳輸對象的數據能否與UI需求相匹配

但是應該/可以將此數據及其結構額外設置爲適合客戶端的綁定需求嗎？

或者我應該額外創建一個ViewModel呢？

它是一個小的應用程序，所以我猶豫太多overarchitecting和dto`s將是90％相同的ViewModels ...

的DTO`s會從寧靜的服務器被轉移到一個JavaScript客戶端不多。

2013-10-31 Elisabeth

我認爲需要考慮的是VM和DTO之間存在的差異。後來，我試圖創建實現，派生或包含DTO合約以及所有視圖中心內容的C＃視圖模型，如選擇列表選項和過濾器屬性。我發現這是繁瑣的，脆弱的和溼的（與DRY相反）。

我後來轉向了一種模式，即在JavaScript中定義我的視圖模型，並允許DTO對象僅包含滿足服務層合同期望所需的屬性。我使用ajax將數據拉下來。數據通常以從服務接收的格式傳遞到視圖中。然後，我更新我的數據綁定，可觀察的挖空視圖模型。到目前爲止，這種模式對我來說確實很有成效。

關於輸入驗證，只要我們談論驗證屬性，我認爲您在DTO上定義驗證屬性是完全正確的。畢竟，您的API控制器具有ModelState是有原因的。不幸的是，將驗證轉換爲客戶端視圖並不是一個好方法。因此，我比MVC的驗證更傾向於基因敲除驗證。然而，我仍然希望有更好的解決方案驗證解決方案！

來源

2013-11-01 05:52:13

你提到ajax/knockout是很好的，因爲我也在客戶端使用它們。事件更多我做了一個SPA，並且我在客戶端和服務器端面對WET很像ViewModels ...或者在客戶端使用更多DRY方式並在服務器端和視圖模型上使用DTO（我將需要它們）。是的，輸入驗證我的意思是驗證屬性（數據註釋屬性）或FluentValidation，這對我在asp.net mvc中運行良好。那麼knockoutjs驗證是好的，但它的客戶端（不安全）我也需要適當的服務器端驗證（modelstate） – Elisabeth

我喜歡考慮用我的ViewModel的線表示來檢索表示。在許多情況下，不需要區分ViewModel和DTO。

來源

2013-10-31 21:03:00

其結果是我的結構化DTO將成爲我的服務器端的輸入驗證模型。 web api控制器。你仍然同意？ – Elisabeth

@Elisa我不會在客戶端和服務器之間共享類型，所以我不會遇到這個問題。我也不會將讀寫視爲對稱操作。但是，對於簡單的場景，您可能會將輸入驗證添加到viewmodel/DTO中。 –

數據傳輸對象的數據能否與UI需求相匹配

回答

相關問題