MVC 4.0: The Role of the View

Excerpt by Phil Ledgerwood | August 29, 2013

The views in your ASP.NET MVC application are what a user sees. Views are the window into your application, and so is one of the most important parts of the application...along with all the rest of it! Views provide one of the biggest reasons to use MVC instead of Web Forms. Unlike Web Forms, you have complete control over the HTML that the application generates. There are no server controls as there are in Web Forms that spew HTML, which you have little control over or that are hard to use with CSS and client-side JavaScript.

Having complete control over HTML sounds great in theory, but it could also mean that you'd have to write a lot more HTML by hand. One of the big selling points of Web Forms is that you can do drag and drop development, using server controls that generate massive amounts of HTML based on the properties you set and the data you bind to the controls. But MVC has a lot of features built in that make the job of writing HTML and other code simpler and more manageable, while letting you retain control over most of the generated HTML. And when you need complete control, you can bypass the MVC features and write all the beautiful HTML you care to write.

The trick to writing good views in MVC is to keep the view focused on the user interface only. This means that there should be no code that directly reads or writes to a data store, no business rule implementations, nothing that isn't directly related to interacting with the user. The ideal view should consist of a lot of HTML, maybe some client-side JavaScript (perhaps including Ajax), and a little code that reads data from the model or ViewData for the purpose of displaying data to the user. It might be appropriate to put some logic in a view, but it should only be presentation logic needed to dynamically interact with the user.

Anything else you should rip out and put in the controller or model. Make that your solemn goal. The purest way to think about views is that the controller hands a model to the view, and the view converts it into something that is presented to the user. We've found this way of thinking to be a helpful context for understanding what views do and how to create them, as well as where to implement different kinds of logic. In this chapter, you'll learn about how views work, how you can add dynamic data to the view, how you can bundle and minify files, a little bit about the view engine that makes it all work, and ways to adhere to MVC's DRY-Don't Repeat Yourself-principle by creating reusable controls that you can use in multiple views.

The Figure below shows a graphic view of the interactions of the components of an MVC application. In order to handle a user request, the controller interacts with the model in whatever way is necessary to respond to the request. The controller then selects a view and passes it whatever data the view requires to generate a page. The view engine then reads the view template and dynamically generates the HTML that is sent to the user.

MVC4 Views The Figure above.

Anatomy of an MVC request and response. In this chapter, you'll learn some of the many features you can use to build views that provide a robust user interface for your applications. The MVC framework has a rich infrastructure for creating responsive and attractive web sites for your users.

  ldn-pledgerwoodThis post is an excerpt from the online courseware for our MVC 4.0: Views and Models course written by expert Phil Ledgerwood.

Phil Ledgerwood

Philip Ledgerwood has been a software developer for fifteen years. He currently works primarily in .NET technologies producing custom software for organizations of all sizes. He has also done extensive training for those same organizations in both technical and business process topics. Philip is a strong advocate of Lean and agile software development and spends most of his time helping companies interested in the value those practices can bring to their development efforts. He does this through a combination of training and working "in the trenches" as a developer on these teams, keeping a hand in the academic side of emerging technology and practices while also directly applying it in real projects to bring real business value.


This course excerpt was originally posted August 29, 2013 from the online courseware MVC 4.0, Part 03 of 11: Views and Models by Phil Ledgerwood