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