在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