Chapter 12. Fat Model, Skinny Controller
Up to this point, the examples in this book have been applying the opposite of a fat model, skinny controller, which is a fat controller, skinny model. The term “fat” implies the presence of business logic; “skinny” implies the lack thereof. This was done to provide focus on the new features that were being shown. In fact, you may have noticed in Chapter 8 when Web API was introduced that the MVC and Web API
AuthorsController contained duplicated code to fetch the list of authors.
That is a perfect example of why fat controllers are convoluted, hard to maintain, and share code between them, whereas the fat model is completely geared toward reusability of code within your application.
Implementing the fat model can be done many different ways, and the depth of organization within can be from one to many layers. This all depends on the complexity of your application.
No matter which approach you take, the end goal of the fat model is to place all of your business logic in the M of MVC. The M should be able to stand alone as a complete application (without a user interface). The V and C that interact to make it MVC can be a console application, a RESTful API, a web application, etc. It shouldn’t matter to the M.
This chapter will provide an overview of common ways to separate the concerns within your MVC application followed by an example of refactoring the two
AuthorsControllers to share common business logic.
Separation of Concerns