Entities Are Not Models

One of the things that drives me nuts about ASP.NET MVC is that all the project templates and sample code equate entities with "models". They're put in a folder called "Models" and they're referred to as "models".

In truth, the terminology is not altogether inaccurate, as a "model" is simply whatever is being worked on by a method, but since the framework is (unimaginatively) named ASP.NET MVC, or essentially, ASP.NET Model-View-Controller, calling things "models" conflates the term to be interpreted as the big "M" of the MVC pattern.

Let's start by defining a few key terms:

MVC
A software pattern that defines a separation of concerns between three distinct components: a model, a view, and a controller.
ASP.NET MVC
An application framework created by Microsoft that is inspired by and attempts to implement the MVC pattern.
Model
The component of the MVC pattern that is responsible for the behavior and data of an application.
Entity
A class involved in data persistence, typically as a representation of a table in a relational database.

A few things these definitions hopefully make clear:

  • Application frameworks are typically based on software patterns such as MVC. However, some application frameworks follow those patterns more strictly or loosely than others. ASP.NET MVC, in particular, follows the MVC pattern, but pretty loosely overall. It has no true Model (by default) and there's small to significant bleed-over between the Model and Controller components and the Model and View components of the MVC pattern. That's not an indictment, but it's important to be aware of.

  • The Model of the MVC pattern is the haven of the application's business logic. In application frameworks that follow MVC more strictly (Ruby on Rails), Model classes are huge objects with tons of logic and methods.

  • An entity is a poor excuse for a Model in the MVC pattern. It's mostly intended for persistence, and though you can add additional properties and methods not intended for persistence, you have to be very deliberate about what gets persisted and what doesn't (the default in Entity Framework is to persist every property with a getter and a setter). There's no clear indication, for the most part, as to which members are persisted members and which are not, which makes understanding the data model a challenge, if the class is used for anything more than simple peristence.

So what is the Model in ASP.NET MVC?

The short-comings of the entity classes referred to as "models" has led most ASP.NET MVC developers to steal a concept from a related pattern, MVVM (Model-View-View Model), namely the view model. In MVVM, the Model component is a simple entity, much as what you have in ASP.NET MVC. It's basically just a DTO (data-transfer object) meant as a way to get data from a database or other persistence-store to the view. The view model in MVVM serves as Shelley-esque combination of the Model and Controller in MVC: it doesn't fulfill either role completely but performs functions of both.

As adopted into ASP.NET MVC, the view model sheds it's Controller-like functions and skews more towards a true MVC-style Model. However, while a true Model would hold the business logic for the application, the view model typically will hold the business logic for the application as it applys to the needs of a particular view or views. It's a slight distinction, but the idea is that you can, and many times should, have multiple view models representing a particular entity class, each tailored to a particular view or set of views.

It is my opinion, at least, that view models, when used in this way, are the closest thing you can get to a true MVC-style Model in ASP.NET MVC. In truth, there are still some aspects that aren't covered. Technically, a Model should also be responsible for querying itself. Selecting, filtering and querying model instances is all business logic, after all, and the Model should hold the business logic of the application. However, this function is inappropriate for an entity class or even a view model. Typically, this role is performed by something like a repository or a service, often referred to as the DAL (Data Access Layer) or, generically, the "business layer" of the application in N-tiered architecture.

So what exactly is the Model in ASP.NET MVC? Well, it's not one thing. Its function is split over three components:

  1. Entity - Holds the data that is persisted.
  2. View Model - Holds the business logic related to presenting that data to the user or allowing the user to interact with that data (forms).
  3. Repository/Service - Holds the business logic related to selecting, filtering, etc. the data from the persistence-store.
comments powered by Disqus