When I first started doing Rails development over a year ago, I often found other developers suggesting that I refactor my code to move the business logic out of the controller, and into the model. After this happened several times, I wondered why this seemed so obvious to them, and why that wasn’t the way I was naturally doing things. It wasn’t just me and another developer approaching problems in different ways. It was multiple people approaching problems in a similar way — and then me. I wondered why there was this general difference in thought processes and solutions?
I began to passively wonder if my background in Java was contributing in some way to my way of thinking here. Since then, I have also heard other Rails developers who are working with former Java developers say things like
"these are good developers but they keep putting business logic in their controllers!"
That made me think more seriously about what a person’s Java background might have to do with this.
In earlier days of PHP, classic ASP, and early JSP, it was OK to put business logic in the view. Back in the day, it was common to find <% %> tags in JSPs with all kinds of logic in the Java code. I think we all now agree that business logic does not belong here.
let the view deal only with DISPLAYING what it has.
It seems like I’ve spent a lot of time seeing a model as simply a data-holder class. Something like a Struct in C. Something like a Bean in Java, with private attributes, and with get/set methods for each attribute. It’s just a data transfer object, nothing more. But why? Perhaps it comes from my EJB days. That might explain why so many other former Java developers do the same thing. To us,
the model carries data but is dumb.
I always thought of the controller as being the one smacking around the model objects to get them to do what the controller wants – and
what the controller wants the model to do, is the business logic.
A RAILS WAY OF THINKING
Give the model more credit.
The model isn’t so dumb after all. It doesn’t just hold state. It contains the business logic behind the behavior of that model. A model knows better than any other code how itself behaves, what it does or does not do, and how it interacts with the outside world. I can try to predict how my brother will behave in a given situation; I can take a guess based on what I know about him. But only he knows for sure, and the only way I can know for sure is to interact directly with him and find out.
Let the controller control the flow of information.
This leaves the controller with only the responsibility of collecting information and routing it to the right place. It’s the electronic curator that finds and obtains art, and hands it off to the decorators to display. He decides what pieces go in which rooms. However, the decorators (analogous to the view) are the ones that decide how to arrange the art within that room for all to see.
I still need to be reminded sometimes to not put so much logic in my controller. It is starting to come more naturally to me, but old habits die hard I suppose. This way of thinking makes more sense to me now that I understand where my past way of thinking comes from. I like this new way because it really makes sense now, and also because
I find that code re-use comes much easier when needed business logic is already available in the model.