In asp.net mvc, I have been thinking it would be more advantageous to specify parametrized constructors on the view classes in contrast to using ViewData to pass data to the view. In this way the view class could be instantiated in the action and returned from there as an implementation of IView for eventual rendering to the client by the framework.
在asp.net mvc中,我一直认为在视图类上指定参数化构造函数比使用ViewData将数据传递给视图更有利。通过这种方式,视图类可以在动作中实例化,并作为IView的实现从那里返回,以便框架最终呈现给客户端。
// 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;}
}
I pose this question because I have personally found strongly typed views pointless as there is not 1 or 0 but n number of objects I would like to pass to the view from the action. I also find the ViewData collection a little too "untyped" to mesh really well with the .net strongly typed world.
我提出这个问题,因为我个人发现强类型视图毫无意义,因为没有1或0但是我希望从动作传递给视图的n个对象。我还发现ViewData集合有点过于“无类型”,以便与.net强类型世界很好地融合。
A parametrize constructor or even public properties on the view would allow the implementer of the view to specify a contract of what data is needed to render the view or can be rendered in the view. This approach would effectively encapsulate the view.
视图上的参数化构造函数甚至公共属性将允许视图的实现者指定渲染视图所需的数据的合约,或者可以在视图中呈现。这种方法可以有效地封装视图。
Why would this be a bad design? What advantages are provided with the "viewdata collection"/"strongly typed view" "way" of passing data from the action to the view. Does anyone think this would be a good idea?
为什么这是一个糟糕的设计? “viewdata集合”/“强类型视图”“方式”将数据从操作传递到视图提供了哪些优势。有人认为这是个好主意吗?
update
I have had a change of heart. What I realized is that the view is really just about rendering. A very good design approach is to introduce Presentation Models that represent the user interfaces available in your application.
我改变了主意。我意识到视图实际上只是渲染。一种非常好的设计方法是引入表示应用程序中可用用户界面的Presentation Models。
If something can be shown or not there should be a Boolean in your presentation model. If something can display text there should be a string for that in your presentation model. The presentation model is not anemic because you use it to encapsulate the logic of your UI. For example, if a field is empty then perhaps some other field is grayed out. This is presentation logic and it describes the way that your particular UI works.
如果可以显示某些内容,则表示模型中应该有一个布尔值。如果某些内容可以显示文本,那么您的演示模型中应该有一个字符串。表示模型并不贫血,因为您使用它来封装UI的逻辑。例如,如果字段为空,则可能某些其他字段显示为灰色。这是表示逻辑,它描述了特定UI的工作方式。
Once a presentation model has been introduced the generic page classes work fine, you simply pass the view the correct presentation model. Presentation models allow you to clean up the code in your view as well as provide portability. If one decided to implement in winforms they would seriously only need to bind their UI to the presentation model.
一旦引入了表示模型,通用页面类就可以正常工作,只需将视图传递给正确的表示模型即可。演示模型允许您清理视图中的代码并提供可移植性。如果一个人决定在winforms中实现,他们真的只需要将他们的UI绑定到表示模型。
Anyway, I just wanted to follow-up because I no longer agree with my original suggestion. I have accepted Travis's answer because this is essentially what he proposed.
无论如何,我只想跟进,因为我不再同意我原来的建议。我接受了特拉维斯的答案,因为这基本上是他提出的。
1 个解决方案
#1
The convention is usually to provide a View Model that encapsulates the data you need in your view. You can then pass this strongly typed object down into your view. So, for example, you might have a BlogDisplay object that looks like this:
该约定通常是提供一个视图模型,用于封装视图中所需的数据。然后,您可以将此强类型对象传递到视图中。因此,例如,您可能有一个BlogDisplay对象,如下所示:
public object BlogDisplayPage {
public string PageTitle {get; set;}
public BlogEntry Content {get; set;}
public IList<Comment> Comments {get; set;}
public IList<BlogEntry> RelatedEntries {get; set;}
public IList<BlogEntry> PreviousEntries {get; set;}
}
Excuse the contrivedness of the example, but I think you understand what I'm trying to get at. This way, you can have all of the data associated with the View in one object that can be easily tested and maintained. This also has the advantage of having strongly typed Views using generics.
请原谅这个例子的假设,但我想你明白我想要的是什么。这样,您可以在一个对象中将与View关联的所有数据都轻松地进行测试和维护。这也具有使用泛型具有强类型视图的优点。
I prefer this over your suggestion of parameterized constructors because its intent is clear, and the creation and aggregation of that data is going to be in one spot that will probably be easier to maintain.
我更倾向于你对参数化构造函数的建议,因为它的意图很明确,并且这些数据的创建和聚合将在一个可能更容易维护的位置。
#1
The convention is usually to provide a View Model that encapsulates the data you need in your view. You can then pass this strongly typed object down into your view. So, for example, you might have a BlogDisplay object that looks like this:
该约定通常是提供一个视图模型,用于封装视图中所需的数据。然后,您可以将此强类型对象传递到视图中。因此,例如,您可能有一个BlogDisplay对象,如下所示:
public object BlogDisplayPage {
public string PageTitle {get; set;}
public BlogEntry Content {get; set;}
public IList<Comment> Comments {get; set;}
public IList<BlogEntry> RelatedEntries {get; set;}
public IList<BlogEntry> PreviousEntries {get; set;}
}
Excuse the contrivedness of the example, but I think you understand what I'm trying to get at. This way, you can have all of the data associated with the View in one object that can be easily tested and maintained. This also has the advantage of having strongly typed Views using generics.
请原谅这个例子的假设,但我想你明白我想要的是什么。这样,您可以在一个对象中将与View关联的所有数据都轻松地进行测试和维护。这也具有使用泛型具有强类型视图的优点。
I prefer this over your suggestion of parameterized constructors because its intent is clear, and the creation and aggregation of that data is going to be in one spot that will probably be easier to maintain.
我更倾向于你对参数化构造函数的建议,因为它的意图很明确,并且这些数据的创建和聚合将在一个可能更容易维护的位置。