Building a Strongly-Typed View
Though using ViewData to pass data from controller to view is workable and sometimes the right thing to do, often it is more appropriate to use a strongly-typed view. A strongly-typed view is a view that defines its data model as a class instead of a weakly-typed dictionary that could hold literally anything.
Programming with Hashtables
Before moving on to the how of implementation or the why of advantages, let us talk principles. Say you have a class that creates monkeys. Would you write it like this?
public class Foo
{
public static Hashtable CreateMonkey()
{
Hashtable monkey = new Hashtable();
monkey["Name"] = "Bob the Monkey";
monkey["Age"] = 5;
monkey["Height"] = 3.4;
return monkey;
}
}
I would hope not. Yet that is no different than using ViewData. There are times for it, like a) when you have no model in your system directly related to the view and think creating one just for that form would be superfluous or b) when you have a strongly-typed view but need to pass to the view a few pieces of info that are not a part of the model. But as a general rule it should not be considered the preferred model.
How To Create One
The Easy Way
For the code sample behind these instructions, you can look at the sample "Strongly-Typed View of a Monkey".
The easiest way to create a strongly-typed view is to use the "Add View" dialog. When you right-click in the Views folder in Solution Explorer and click "Add View", you are presented with a dialog. Here is a picture of the dialog with the options selected for creating a strongly-typed view for a Monkey:
In all respects save one, a view created with those settings is unremarkable compared to a weakly-typed view. But that one difference is very important, and it looks like this:
<%@ Page Title="" Language="C#"
MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage<HowMVCWorks.Models.Zoo.Monkey>" %>
It is that last bit that is important. Note that the ViewPage class is (or can be) generically typed, allowing a specific type to be defined for that ViewPage. When you create a strongly-typed view, you are tying that ViewPage to a specific type of model (as in "model-view-controller"). This is nice in that it allows you to reference Model in the markup of the view, which is a much more pleasant developer experience than dealing with an untyped dictionary.
Creating a Strongly-Typed View Manually
If you create a view and later need to convert it to a strongly-typed view, the process is quite simple. Change the "Inherits" statement in the view declaration from System.Web.Mvc.ViewPage to System.Web.Mvc.ViewPage<YourNamespace.YourClass>.
Handing the Model to the View
Once a view is strongly-typed, the controller has to pass to the view the model that it uses. As a review, when a view is not strongly-typed, the controller action might look something like this:
public ActionResult StronglyTypedViewOfAMonkey()
{
Monkey monkey = new Monkey();
monkey.Name = "Bob the Monkey";
monkey.Age = 5;
monkey.Height = 4.5F;
ViewData["monkey"] = monkey;
return View();
}
To pass this monkey to the view in a strongly-typed fashion, however, would look like this:
public ActionResult StronglyTypedViewOfAMonkey()
{
Monkey monkey = new Monkey();
monkey.Name = "Bob the Monkey";
monkey.Age = 5;
monkey.Height = 4.5F;
return View(monkey);
}
The object that is being used as the model is passed into the View method, which associates the instance of Monkey (in this case) with the view.
Because the View knows the class of its Model, the values can be referenced like the following:
Monkey Data:
Name: <%= Model.Name %>
Age: <%= Model.Age %>
Height: <%= Model.Height %>
Advantages
I am a big fan of strongly-typing my views for two reasons:
Expresses Better Semantics
As was mentioned above, programming with instances of Hashtable all of the time would work but is a semantically poor way of expressing your intent. By strongly-typing your views, there is no confusion on what data your view should be expecting.
This also improves semantics for testing. If you are one who writes automated tests you will probably write tests for your controllers. And if you do, getting a strongly-typed view from your action method is easier to deal with than Hashtables.
Intellisense
If a view is strongly-typed, Visual Studio's intellisense will be able to help you. If you are using the bland ViewData, Visual Studio can make no assumptions and can provide little aid.
Speak Your Mind!
Have something to say? Find a grammatical mistake? Think I said something incorrect? Don't like my perspective? Hate my color scheme? Whatever it is, you can let me know. I would appreciate it if you did.
