在asp.net mvc中,我一直認爲在視圖類中指定參數化構造函數會比使用ViewData傳遞數據到視圖更爲有利。通過這種方式,視圖類可以在動作中實例化並從那裏返回,作爲框架的最終呈現給客戶端的IView實現。應該參數化ASP.NET MVC視圖
// An example of an action that returned one of two
// views while passing a data objects from the current
// scope.
IView MyAction(discriminator){
if(discriminator){
return new MyView(SomeVal, SomeVal2)
}else{
return new AnotherView(SomeVal1)
}
}
// An Example Definition for IView
public interface IView{
Render(stream OutputStream);
}
// An Example View Code Behind/Partial Class
public partial class AnotherView{
public AnotherView(string GimmeData){
this.GimmeData = GimmeData
}
// This value could be accessed in the markup like:
// <%=this.GimmeData%>
public string GimmeData {get; set;}
}
我提出這個問題,因爲我曾親自找到強類型的觀點毫無意義的,因爲沒有1或0,但ň對象的數量,我想傳遞給從行動的觀點。我還發現ViewData集合有點「無類型化」,與.net強類型的世界非常吻合。
參數化構造函數或視圖上的公共屬性將允許視圖的實現者指定呈現視圖所需的數據或可在視圖中呈現的數據的約定。這種方法將有效地封裝視圖。
爲什麼這是一個糟糕的設計? 「數據集合」/「強類型視圖」將數據從動作傳遞到視圖的「方式」提供了什麼好處。有沒有人認爲這是一個好主意?
更新
我有心臟的變化。我意識到的是,這個觀點其實就是渲染。一個非常好的設計方法是引入代表應用程序中可用用戶界面的Presentation Models。
如果可以顯示或不顯示您的演示文稿模型中應該有布爾值。如果某些內容可以顯示文本,則在演示文稿模型中應該有一個字符串。演示文稿模型不是anemic,因爲您使用它來封裝UI的邏輯。例如,如果一個字段爲空,那麼可能某個其他字段變灰。這是表示邏輯,它描述了特定UI的工作方式。
一旦引入了表示模型,泛型頁類就可以正常工作,只需將視圖傳遞給正確的表示模型。演示模型允許您清理視圖中的代碼並提供可移植性。如果決定用winforms實現,他們會認真只需要將他們的UI綁定到演示模型。
無論如何,我只是想跟進,因爲我不再同意我原來的建議。我已經接受了特拉維斯的回答,因爲這實際上就是他提出的。
謝謝特拉維斯。我熟悉這一慣例,但沒有看到優勢在哪裏。對我來說,似乎我們不得不創建這些不相關的持有者類作爲解決方案,將多個對象傳遞給視圖(顯然我們需要共享)。爲什麼我們不應該在視圖上使用屬性?如果我們確實希望這種貧血模型能夠傳遞數據,我們不能僅僅通過一個參數傳遞給構造函數嗎?爲什麼使用通用? – 2009-04-22 05:36:43