"Model" Is an Overloaded Word

Let's say you're writing a web application, and using the Model View Controller design.  Maybe you're using an out-of-the-box framework like the ASP.NET MVC Framework or Rails, or maybe you're using a different implementation; it doesn't matter.  It's pretty obvious that the "View" portion of the design is the part which provides a template for rendered HTML, and that the "Controller" portion of the design is the part which handles requests, specifying the general outline for what should be returned to the user.  But what about the "Model?"

Most non-trivial applications have many different models, and for good reason.  If the application uses a relational database, it will have a relational model.  A non-trivial web application may use an application server, containing an entity model with an object-relational mapping, perhaps based on a framework like the Entity Framework or NHibernate.  In some designs, these entity types are not exposed from the application server, but rather represented as lightweight data access objects.  These data access objects are made available to clients of the application server, such as a web application.

Inside the web application, it's possible that the lightweight data access objects will be made available directly to the View, without being wrapped up inside any other type.  But it's more likely that additional information will need to be passed to the View, requiring the use of an additional model type, which wraps up the information required by a particular View.  Or, a View might require a different representation of the data access objects, such as XML or JSON.

So let's count the different types of "Models" I've listed so far:

1. Relational data model


2. Entity model, perhaps with an object-relational mapping


3. Lightweight data access objects


4. View-specific models

To be clear, I don't think the existence of multiple types of models is by itself a problem.  But I do think that the overloading of the term create some confusion about how to follow the MVC application design.

When you create a new ASP.NET MVC web application, Visual Studio creates a Solution containing a single project for the web application itself, with a folder called Models.  Many of the demonstrations of ASP.NET MVC projects that I've seen drop a LINQ-to-SQL model inside of this folder.  I understand that people like to keep their demonstrations simple, but as a rule I think that any type of object-relational model should be in a separate assembly from the web application, along with any business logic implementation required.  This second assembly becomes the API for your data which the web application will use.  It can be a web service, or an assembly which exposes methods for accessing the data directly, e.g. with the Repository pattern. However, I keep the Models folder in the web application, and use it for "View models," which handle things like pagination, aggregation of multiple instances required by the view, etc.

Maybe MVC should stand for Models View Controller?

In the second part of this series, I will examine additional types of models, and the general problem of transforming one model into another.