The WHY Series: Why should your controllers be thin?
There are a lot of shoulds in the dev world.
We are told we should keep functions small. We should keep check-ins small. Our controllers should be thin.
But why?
We’re not always told why. Or we are, but it’s not clear, or not convincing enough.
For that, thus begins the first in a series of brief articles called…
The WHY Series
To begin, let’s talk about why I think controllers should be thin.
No more shoveling code from one layer to another just for the sake of it.
Why should your controllers be thin?
Firstly, the word “should” is so pushy, isn’t it. I like to think most patterns are best seen as suggested guidelines based on some past fuck up. Avoid fucking up by considering guideline x. It may not fit your situation exactly, but they rarely do.
Let’s look at the inverse – If controllers are not thin, then what?
Well, they’d have to be fat, meaning the method bodies are large and/or the controller classes have a lot of business logic in them. Fat controllers mean they are doing a lot of work. That could mean they are doing too much work or the wrong kind of work.
It's a code smell.
A controller is mainly there to route requests thru some sort of processing and return a result. If a controller is fat, that could be because it’s doing a lot of the processing itself and that could be an issue because controllers don’t process. Generally your business layer handles that.
Developers and Plumbers
Imagine you hire a plumber to hook up your kitchen sink. When you come home, you find that the sink works great but the plumber has routed the pipe directly through the center of kitchen so you have to duck under it to get to the other rooms in your house.
There are lots of ways to get the job done, but some ways are better than others. If we want to make life easier for the next developer, we should do our best to keep things tidy and easy to change.
So when you’re writing that controller code… remember that smell!
Oh, and this post has a very important addendum!.