MVC中的多視圖vs一個「複雜」視圖

這是我們回顧過程中的一次，希望得到一些額外的反饋和抽查。我們目前有許多基於布爾標誌啓用/禁用的視圖（Model.IsNew就是一個例子）。我認爲視圖應該儘可能簡單，控制器應該確定該視圖的數據，而不一定是如何工作的。我認爲，部分或全部的觀點應該是「應該」 - 應該做什麼，如何處理這些觀點以及確定應該顯示/隱藏的觀點。一個非常基本的例子如下，但涵蓋了這兩方面，並且大多反映了我們所擁有的...MVC中的多視圖vs一個「複雜」視圖

控制器有一對名爲Details的方法（post/get）。 [Get] Details有一個參數，Id和[Post] Details分別是id和viewmodel。在這篇文章中，該方法約30行，檢查有效模型，確定它是否新增，如果某個值發生變化（觸發重定向）等等（我認爲這是不正確的）。 [獲取]詳細信息檢查空ID，填充必要的下拉列表，沒有什麼奇特的（我認爲這是正確的）。詳細視圖本身包含一小部分邏輯：如果（！Model.IsNew）{RenderAction（History => History.Show（id）;}（我認爲這在if中是不正確的，Show應該知道顯示什麼，不管它是否是新的）。對此的補充是所述細節視圖的佈局不會做兩次細節/添加將幾乎相同，根據狀態減去一些禁用的字段（也許這些應該是部分？） - 實體可以禁用/刪除使值可編輯與否。

思想，觀點，見解？

來源

2010-11-29 jeriley

爲什麼不創建多個視圖和操作？

Details 

Edit 
[HttpPost] 
Edit 

Create 
[HttpPost] 
Create

然後，他們可以共享一個模型對象

public ThingModel 
{ 
    public Thing Thing { get; set; } 
}

或有創建和編輯的操作使用更安全（防止HTML注入）模型，這也將讓你使用內置的驗證選項。

public ThingEditorModel 
{ 
    public int Id { get; set; } 
    public string Name { get; set; } 
    public string Value { get; set; } 
    public bool IsNew { get { return Id == 0; } } 
}

然後對於編輯和創建，您可以創建創建和編輯可以共享的EditorTemplate（共享/ EditorTemplates/ThingEditor.ascx）

來源

2010-11-29 18:50:08 hunter

我同意，我認爲越多越好，在可能的情況下可以更好地重複使用和濫用，並將其包裝在一個表單中。好，所以我沒有脫離基地？ – jeriley 2010-11-30 03:04:51

我認爲你在正確的軌道上...使用'main'視圖佈局，然後使用模板助手獲得'邏輯'。依靠Html.DisplayFor（x => x.Thing）和EditorFor

你肯定不希望佈局在兩個地方。

來源

2010-11-29 18:57:03 Webjedi

不知道爲什麼有人會把這個投下來......和我的想法一樣 – hunter 2010-11-29 19:35:00

MVC中的多視圖vs一個「複雜」視圖

回答

相關問題