Asp.net MVC – When to use strongly typed ViewData?

In short; all of the time unless you have a *really* good reason not to.

With the use of generics being able to specify a strongly typed model per view / partial view is so easy with the baked in functionality in the framework, so why aren’t you using it?

Why?

The whole point of MVC is to have control over markup, enable specific routes and reuse existing views / partial views in different locations among others. It’s not to make your life harder than it already is. The underlying issue is if you don’t have the a strongly typed view model for each view then you don’t have confidence in having complete control over it. Throw in a dev team, potentially, changing the same weakly type code and you’re looking for pain.

When you first start looking at examples of MVC applications, you find examples where people start putting in values in to the ViewData dictionary which is available on the views/controllers.

ViewData["MyKey"] = "Some string value";

This uses the weakly typed ViewDataDictionary which can lead to issues with keys not being present, casting it to the wrong type (potentially) and can lead to unnecessary complexity beyond what is required. This can create hard to maintain spaghetti code in the view markup (can anyone say “classic asp 3” ?) … all of which is bad.




So are you suggesting a ViewData model class per view?




Yes; this is exactly what I’m suggesting. This leads to well structured solutions and keeps the code and views together. This isn’t such a big problem when working on your own, but if you know the system you are writing will be a lot bigger when completed or you work in a bigger team (or both) then it’s better to keep things as simple and clear as possible as early as possible. Set a good foundation to work from.





So my current Visual Studio project layout looks something similar to this :

 



The view data class definitions and the associated full / partial views are filed away in similar namespaces / folder structures * underneath their associated areas of the solution so that you know which are linked together more easily.





* The views in this case are filed under Document instead of Documents because of the name of the controller, although are potentially incorrectly named  :-)




Summary

So to summarise, why do this? Well it helps to know what you’ve got to play with in each view. It breaks down the specifics which you need to pass into a view/partial view to get it to operate nicely. It also means when re-using partial views you know what to pass into them. Also, with strongly typed goodness it helps with refactoring especially when using tools such as Resharper.





Let me know your thoughts.


Further reading:

MikesDotNetting - ASP.NET MVC Partial Views and Strongly Typed Custom ViewModels