I hate referencing anything with a hardcoded string. Configuration settings, dictionary, whatever. In such cases I’ll use constants, or wrap it kind of like you did. I do this with configurationmanager calls all the time.

One the goals to this was to have a single interface to interact with the view page. In the approach of using a ModelBinder and a typed viewpage, I have two different methods of interacting with the view (depending on if I’m retrieving information or sending information).

On top of that, I have to write additional classes for the ModelBinder and if I need to use more than one object to send to the view, I’m writing wrapper objects that exist only because I’m wanting to interact with the model in a way that isn’t natively supported. At that point I feel like I’d be losing the advantage of what you’re prosposing here, as there isn’t too much difference conceptually between writing a wrapper for multiple objects and what I’ve posted above.

Not saying my way is better, but I don’t really think the level of effort involved is greater than the proposed alternative. Additionally, all code dealing with it is located in one place.

public partial class AddUser: ViewPage

Then in my controller, I add the user to its view like so:

this.ViewData.Model = _userRepository.GetUser(id);
return View();

If there is more then one object I need to pass, I do something similar and make a very small wrapper class. So if I had to pass a User and an array of Photos for example, I might already have a User object and a Photo object in my domain, and wrap them like this:

public class AddUserModel
{
public User User {get;set;}
public Photo[] Photos {get;set;}
}

then change my view to do this:

public partial class AddUser: ViewPage

similar to what you’re doing, but less work because I’m using existing business objects rather than making a wrapper around all the ViewData dictionary stuff.

Yeah I’ve looked at Binders… they look cool. The point of what I have here was supposed to be that you use one instance (in this case AddUserView) to either pull values from the form or send values to viewdata.

Also, this was before we moved everything to preview 5.

In terms of actual work, like most classes once it’s set up it’s a simple matter of leveraging the functionality. Plus it simplified things for the developers I’ve been mentoring on ASP.NET MVC … just create a view, inherit from this class and then all access is pretty much the same. Get and Set. I find that repeatable patterns help people when they’re first learning something.

I’ve no doubt that this could be better implemented, or there are better approaches, though, but it worked for us.