在ASP.NET MVC中開發時,我使用1:1 ViewModel設置,其中viewmodel僅包含視圖所需的數據。我也使用數據註釋來驗證視圖模型。數據註解和MVC 1:1 ViewModel
我擔心的是,這並不是遵循DRY原則,因爲我發現自己不得不在整個我的網站上重複驗證。我很想在一個地方進行驗證(我的域模型),但因爲我從未將域模型發送到視圖模型,所以這是不可能的。
我想知道是否有其他人遇到了這個問題,並找到了解決此問題的適當方法或有更好的解決方案?
在ASP.NET MVC中開發時,我使用1:1 ViewModel設置,其中viewmodel僅包含視圖所需的數據。我也使用數據註釋來驗證視圖模型。數據註解和MVC 1:1 ViewModel
我擔心的是,這並不是遵循DRY原則,因爲我發現自己不得不在整個我的網站上重複驗證。我很想在一個地方進行驗證(我的域模型),但因爲我從未將域模型發送到視圖模型,所以這是不可能的。
我想知道是否有其他人遇到了這個問題,並找到了解決此問題的適當方法或有更好的解決方案?
當我們採用1:1的ViewModel方法時,我們也有類似的擔憂。我們發現:1)重複數據比第一次出現時少; 2)應用程序的整體可維護性和功能得到了充分改進,使得任何非DRY成本都值得。
我們最終考慮了從不同視角(關注點分離)對ViewModel和領域模型的驗證。在域級模型中實施驗證時,我們正在尋找全面的安全性來防止攻擊。我們還檢測到嚴重的「合同」違規行爲,這些違規行爲表明上層的錯誤。在視圖模型中實現驗證時,我們嚴格關注可用性。
如果你從這些不同的角度來看模型,那麼你可能會認爲重疊較少。出於可用性的原因,域圖層可能允許您在ViewModel中限制某些操作。或者,ViewModel可能會假定只發布渲染視圖的輸入,依靠域模型進行全面的安全驗證,旨在防止攻擊。
1:1 ViewModels也極大地簡化了可測試性。 ViewModel的測試可以獨立於領域層來編寫,這使得單元測試更輕,更易於維護並且通常更有用。同樣,您可以在不考慮輸入如何流經用戶界面的精神扭曲的情況下測試域模型。這也符合「縱深防禦」的安全原則。
我們也注意到,視圖的變化比領域層更爲頻繁。知道你的域模型具有非常好的安全單元測試覆蓋率,並且當你實現一個新的View時,你只需要從可用性的角度來考慮驗證就可以很安心。
最後,如果您預計有一個Web服務層,您會發現域和視圖模型的分離支付股息。沒有它,域模型不可避免地會被寫入來支持UI。當您在服務界面上進行分層時,您會發現阻抗不匹配。
如果最終確實存在重大重複,則可以始終單獨對驗證進行分解。根據我們的經驗,上述討論的所有原因並不值得。
感謝@Rob,你介紹了我的主要擔憂!我想我會得到更多的人的反饋,但似乎沒有:S – WDuffy 2010-06-06 10:30:55