在asp.net(webapi + mvc)項目中,我有很多dto作爲我的BLL的公共接口。此外,我的大多數視圖模型與適當的dtos相同。DTO vs VM - 使用還是不使用?
智能書籍告訴我們,我們必須分開這種模型,但在項目上我看不出這個解決方案的好處。只有數百個無用的代碼有很多愚蠢的錯誤。
所以 - 在可能的情況下使用DTO作爲視圖模型是否正確?這種解決方案的積極和消極影響是什麼?
在asp.net(webapi + mvc)項目中,我有很多dto作爲我的BLL的公共接口。此外,我的大多數視圖模型與適當的dtos相同。DTO vs VM - 使用還是不使用?
智能書籍告訴我們,我們必須分開這種模型,但在項目上我看不出這個解決方案的好處。只有數百個無用的代碼有很多愚蠢的錯誤。
所以 - 在可能的情況下使用DTO作爲視圖模型是否正確?這種解決方案的積極和消極影響是什麼?
數據傳輸對象只是要在邏輯邊界和物理邊界之間傳輸的數據的子集或超集。他們不能提供行爲。他們只是數據。
在另一方面,視圖模型是數據和行爲的混合,因爲它們是給定視圖的邏輯端。
因爲DTO和VM是涵蓋不同用例的模式,所以最終會產生無用的數據和行爲,並且可能會添加不需要的依賴關係。
例如,DTO可以在域和應用程序層中使用。如果您在單個類中同時使用DTO和VM概念,則最終可以強制域項目添加對UI庫的引用以構建它。我會盡可能避免這種情況。
另外,你知道有所謂的繼承一個面向對象的概念,它可以在這裏爲您提供幫助,以保持乾爽(不要重複自己):
public class Base {}
public class Dto : Base {}
public class ViewModel : Base {}
總之,你可以分享DTO和通過繼承來查看模型的共同點,並避免代碼重複。
Thx toMatíasFidemraizer的詳細解答。除此之外,我發現了幾個實用和必要的應用程序。
在使用虛擬機作爲單獨的實體的情況下,您添加了一個額外的靈活點。最常見的情況是前端數據的格式和/或結構變化很小。第二種情況 - 您的VM可以編寫來自多個DTO對象的信息,因此您可以保留您的Bll代碼而無需任何更改或最小化它們。 S.O.L.I.D.作品。
但最有用的部分是單元測試。你可以更容易地測試你的bll,因爲你的DTO對象可以簡單明瞭。你也不應該被映射錯誤所困。
'DTO' **作爲**基類如何?簡單的將VM轉換爲基類生成DTO(不需要複製任何東西)。 – Sinatr
@Sinatr由於我是ortodox,我不想讓下面的陳述成爲一個真相:'if(vm is Dto)':\ –