我們目前使用 DTO 進行 Web API 請求和響應并使用 ViewModel 將數(shù)據(jù)傳遞給 MVC 中的 View目前，我們有：DTO 作為一個單獨的項目ViewModel 位于 UI 項目中（與 Controllers 一起的另一個文件夾）我在我們的案例中看到的唯一區(qū)別是 DTO 必須通過線路傳遞并作為 JSON 發(fā)送，而 ViewModel 必須在視圖內(nèi)部傳遞才能呈現(xiàn)為 HTML。我們應該為 MVC 應用程序和我們的應用程序/其他客戶端維護單獨的傳輸對象，還是僅通過 DTO 來完成這兩項工作，即在 View 而不是 ViewModel 中傳遞 DTO？它可能有什么缺點？我在這里閱讀了很多回復，但沒有示例和令人信服的理由在我們的案例中保留單獨的 ViewModel 和 DTO。
3 回答
DIEA
TA貢獻1820條經(jīng)驗 獲得超3個贊
我可以分享我在項目中實施這種模式的經(jīng)驗。將該項目視為分布式架構的簡單CRUD應用，分為三種方案：
Project.Web（MVC 應用程序）
Project.DTO（普通 C# 類）
Project.API（Web API 應用程序）
Project.Web 包含應用程序的 UI 邏輯，并且所有 CRUD 操作都依賴于 Project.API，因為與數(shù)據(jù)庫相關的操作是在 Project.API 中執(zhí)行的。
現(xiàn)在來了 Project.DTO，它包含普通的 C# 類，用于來回傳輸數(shù)據(jù)。
Project.Web <---> Project.API
為了使其更具分布式，我創(chuàng)建了 Project.DTO 作為 Nuget 包并將其托管在 Artifactory（您可以使用 Nuget 或任何其他存儲庫）并使用 Nuget 包管理器使用它。這種方法的主要優(yōu)點是 DTO 類始終是版本化的并且易于使用。
關于保持 View Model 和 DTO 分開的問題，我可以看到以下幾點支持它：
從 API 到 Web 的數(shù)據(jù)傳輸，反之亦然：它可能很大而且很復雜。假設我的應用程序想要創(chuàng)建一個客戶端并將其所有詳細信息添加到數(shù)據(jù)庫中，例如客戶端地址、客戶端通信、客戶端歷史記錄等。在 Project.Web 中，我們可以擁有其他詳細信息，例如會話相關數(shù)據(jù)、需要的 UI 特定數(shù)據(jù)不需要從 Web 傳輸?shù)?API。因此，創(chuàng)建一個單獨的 DTO 是有意義的，只傳輸 Web 和 API 通用的并且獨立于項目的數(shù)據(jù)。
對 API 或 Web 的傳入請求：假設我已經(jīng)創(chuàng)建了一個移動應用程序并準備使用 Project.API。如果我沒有創(chuàng)建單獨的視圖模型和 DTO，我應該將我的視圖模型公開給客戶端（移動應用程序），這是不可取的，因為它可能包含應該保密的敏感字段。
關注點分離：保持 DTO 僅用于傳遞數(shù)據(jù)，對于應用程序中的任何其他進程，請使用 ViewModel。保持關注點分離原則。
這些是我能想到的與您的問題相關的幾點。
- 3 回答
- 0 關注
- 355 瀏覽
添加回答
舉報
0/150
提交
取消