The fact that ASP.NET MVC’s default view engine is built on top of Web Forms brings a lot of advantages, key among them being familiarity for existing ASP.NET developers. The bee-sting notation (<%= %>) has been around for quite a while and a lot of the code you put inside it looks pretty familiar to Microsoft’s web developer crowd.
The drawback to this familiarity is that it’s easy to start using Web Form-based development habits within your views, especially around the sourcing and retrieval of data. This can cause maintainability issues because views are one of the hardest parts of an application to accurately and robustly test. Lots of testing products exist, along with tools like Selenium and WatiN, but it’s hard enough to get applications to look and work consistently across different browsers, let alone build a holistic and resilient UI test suite. That’s why it’s so important to keep your views clean and devoid of all but the simplest logic.
A common pitfall when moving to MVC is to not rely on the framework’s methods for passing data from controllers to the view. For instance, in Web Forms-based applications, it’s not all that uncommon for ASPX pages to go digging around in session state for data. In an MVC application, however, this is a violation of separation of concerns, as the view now possesses knowledge for where data is being stored (or at least cached), and is bypassing the controller’s sovereign rights to provide the view with all the data that it needs. Remember, the controller’s purpose in life is to orchestrate processing and pass the appropriate data to a view for rendering.
If the view needs data that’s stored in the session (or elsewhere) it’s the controllers job to retrieve it and provide it through the standard way of transmitting data from controller to view: ViewData. If the view needs a lot of disparate data to perform it’s duties, it probably means you’re in need of a view model object that ties all that data together in a format the view can easily work with. The importance of view model objects shouldn’t be overlooked. They are distinct from the domain model classes typically outlined in MVC discussions and are a critical component to building anything more than the simplest MVC application.
This brings us back to why the Web Forms view engine can be a slippery slope, allowing us to fall into the pit of despair even though its familiarity makes it seem like the pit of success. Since it, like the rest of ASP.NET MVC, is built on top of ASP.NET you can access all those old properties and objects to poke around directly in session, or even the request, to get values and data the view may need. My advice when those temptations arise is to fight the urge, make sure the controller provides your view with all the data it needs and develop as though you don’t have access to such functionality. Your applications will be better off for it.
This post targets Visual Studio 2008 and ASP.NET MVC 1.0 .The content may not be relevant for other product, framework or language versions.