Should ASP.NET MVC Views be Parameterized

Question

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.

// 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.

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?

---

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.

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.

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.

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.

Answer 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:

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.

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.