Fat Controllers vs Fat Models - The Turning Gear

Fat Controllers vs Fat Models

Michael Hudelson 11.20.2018

Fat Controllers vs Fat Models

In the world of web development, most people have heard of the Model View Controller (MVC) design pattern. For those of you who need a quick refresher, MVC is a design pattern used to separate the data (models), the logic (controllers), and the presentation (the views). It is the most widely accepted architectural standard for web development.

The Problem

Widely accepted, however, does not mean widely understood or even correctly used. One of the biggest debates around MVC is around where the business logic should go. Should we put the business logic in the models and create a so called “fat model”, or should we put it in the controllers to create a “fat controller”.

The Case For A Fat Controller

The idea of putting the business logic in the controller is reasonable. Afterall, the point of the controller is the control the flow of the application. However, it is my opinion that this is asking the controller to do too many things, ie controlling the flow of the system and the controlling the business logic.

The Case For A Fat Model

Many would say that putting the business logic with the associated data models would be best since it keeps the business logic close to what it will be working on. I also do not think this is the best place for it since often times business logic needs multiple sources of data, resulting in the question of which model the logic should be tied to.

A Better Way

I think we need to stop looking at this issue as a matter of either fat controllers or fat models. The reality is that models, views, and controllers already have well defined usages. They work together in separating the concerns of system flow, and that should be enough. We should instead look at adding an additional layer for business logic. A sort of service layer that can be called from the controller. It allows the controller to continue to do what it is meant to do (control the flow of the system), while handing off the responsibility for the business logic to something else. This service layer can then interact directly with the models it needs to, while allowing models to do as they were intended (represent data). By building out a service layer concept, we are able to maintain the separation of concerns provided by MVC, while also building out our service layer in whatever way makes sense for the specific system we are working on.


Do not look at this as a matter of either fat models or fat controllers. Instead, let the models, views, and controllers do there job while adding in a service layer that can represent your system’s business logic in whatever way makes sense. Your service layer could be functional or object oriented. It can even (and probably should) have its own architectural patterns. By taking this approach, you will be able to build systems with better separation of concerns, and in turn, are far more maintainable.



9 + 6 =