MVC as a pattern has many interpretations, but an interpretation I think is common goes as follows:
There is a distinct problem with this, and it's that the controller is bloated with all manner of code - things which don't seem bottom-up enough to be part of the model, or code to pre-chew model data for the benefit of dumb templates. This leads to controllers dozens of lines long that are difficult to read as a whole.
In my code (Django code, where controllers are called views) I have been try to avoid this, for a long while now. Since controllers constitute the glue between request, model interaction and setting up of the view, I read these frequently to determine how the application is glued together. Therefore I've found them to benefit from being as short and transparent as possible.
These facts should be immediately visible on reading the code of a controller:
I think it's worth formularising this. My take would be something like this:
A controller should contain no code other than these distinct phases:
These can even be labelled as such.
I've conflated unpacking/validating because these can generally be stated succinctly together, using trivial code. For example, in Django, you'd see code like this:
def category(request, category_id): category = get_object_or_404(Category, id=category_id)
which I think succinctly comprises these facts:
When identifying the business logic of a view, I've found that when the code enacting this grows to more than a couple of lines it's best either to be put into a form's .save() method (thus a form basically defines one operation on a mixed bag of unvalidated input), or into model methods (usually for simple model manipulation), or into a separate class that defines more complicated business logic.
When reading the template context setup, I want to know, when writing templates, what variables I have. Thus this should be explicit in the code of the controller I'm looking at.Comments powered by Disqus