Tag Archives: MVC 4.0 Views and Models

What is a Model? – MVC 4.0: Views and Models

The model in the model-view-controller pattern is the representation of the domain in an MVC application. The domain of an application is the problem area the application deals with, usually classes that represent business objects. For example, an online banking application might have a domain that consists of checking accounts, transfers, and bills. An application to manage a pet store’s inventory might have a domain that includes cats, dogs, and pet food. The model of your application consists of the classes that represent this domain.

To be consistent with the principle of separation of concerns, views and controllers should have no knowledge of the business rules in your domain or where the data for your domain is stored—if there is even a persistent storage for the data. Instead, views and controllers interact with the model and other application layers to handle those details.

Most real-world MVC applications will typically make use of some sort of data that is stored somewhere, usually in a relational database such as SQL Server or Oracle, or, at the very least, XML files stored on a server somewhere. No matter what the storage is, the application will contain some kind of data access layer to read and write data. Similarly, all non-trivial applications always have some kind of business rules, ranging from simple requirements that a customer’s last name be provided and that an email address must comply with Internet standards, to rules like all customers who did more than a million dollars’ worth of business with us last year get an automatic 20% discount on all purchases. These business rules may be handled in other layers of the application, but the rules that govern a specific object are present in the model.

Unlike a controller or view, in an ASP.NET MVC application a model is not defined by implementing a specific interface or inheriting from some framework class, or even because the class definition file is in the Models folder in Solution Explorer. Instead, one or more classes are models because of the role they play in the application.

This gives you enormous flexibility in how you implement a model. A model could be a simple class that represents data generated during a single session of the application, destroying the data when a user signs off. It could be a complex set of classes generated by Entity Framework to provide an objectrelational mapping to a relational database with hundreds of tables. Or just about anything in between. You’ll see variations of these options in this chapter. But at its core, a model is just a class that lets the controller interact with your domain and that provides data in that domain to a view.

TIP: A model is domain specific. This means that although you can implement a model just about any way you want, you generally will not want generic ADO.NET objects, such as DataSets, to serve as models. Instead, you’ll normally build a model for a specific application (or set of related applications) that serve specific data and business rule needs.

If a model you build is specific to a single application, you should create the model classes in the Models folder within Solution Explorer. This convention makes it simpler to work with the model classes and makes them easily discoverable when another developer comes along six months from now and tries to figure out what you did. But you can place a model class anywhere within an application. Remember that it is how a model is used that makes it a model, not where it is located or what it implements or inherits from.

If you use a model in several related applications, you can put one or more models in a class library and compile it into a standalone DLL, which you then reference from the applications that use the model.

A best practice in MVC applications is to maintain the separation of concerns between the components of the application. For models, this means that you’ll want to instantiate (or retrieve) the model in the controller’s action methods, using the methods and properties of the model to tell the model what actions to take relative to the data, and then send the data to a view for display to the user.

This chapter explores the use of models in an ASP.NET MVC application, how you can create them, and how you can implement validation rules. You’ll also explore how to interact with models from views and controllers, since none of these components exists in a vacuum. Models, views, and controllers interact in specific ways, so it is impossible to consider models without considering the other components as well.
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 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.

MVC 4.0: The Role of the View

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 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.