The Future of Controllers: What Does the Controller Do?

That reasonable best practice is to imagine that you had to expose your model to a Flex front end (or AJAX calls or SOAP or REST/XML requests). The rule of thumb is that if you have to replicate any code to make this work or feel that you need to call your HTML controller then you’ve probably put your business rules into your controllers and you should consider refactoring to make your model capable of being called in multiple ways by different classes of front ends.

What is interesting when you follow that advice religiously is how little there is left for the controller to do . . .

When I took the time to think about what should be handled by the controller, all that I could come up with was providing well-parameterized method calls using the URL, form and session scope, handling extremely limited navigational logic, and passing the results from the method calls to the right view(s) to build each HTML response.

Well Parameterized Method Calls
When it comes right down to it, the job of a web application is to allow you to execute commands and return the values of queries (in the widest sense of “requests for information” – not necessarily database calls). As an interesting side note, there is a great article on Wikipedia about command-query separation - the idea that every method call should be either a command (which has the potential to affect state – i.e. which may have side effects) or a query (which returns data without affecting it).

I have found that the vast majority of web requests can be modeled in terms of adding, editing, viewing, listing, authenticating, deleting, publishing, importing, exporting or reporting on a collection of one or more objects, and I am also finding that by looking at each web request as one of those categories of actions I’m able to create little domain specific languages allowing me to declaratively specify most of my model methods and to automate the generation of the vast majority of my controller code.

In general terms, if I am adding or editing data, I probably want to take information from the URL and/or form scopes, put it into the appropriate bean and the pass that to an add or edit service method (or call add or edit methods against the bean if I’m using a more “active record” style approach). If I am listing, viewing, authenticating, deleting, importing, exporting or publishing data, I typically just need to pass a small set of URL or (more occasionally) form based parameters to the appropriate model methods. It doesn’t seem like an unreasonable reach that a custom framework could be developed to do all of this through convention while still providing the flexibility to create a wide range of web applications (although possibly not the flexibility of a true general purpose framework like MG or M2).

Of course, any HTML controller must also handle session authentication in a manner that will integrate with the model.

Navigational Logic
One of the great things about M2 and MG is that they have great tools for handling navigational logic. With filters and plug-ins and listeners and events and event handlers there are a range of tools for handling really sophisticated navigational logic. But how much sophisticated navigational logic should really be in the controller? Obviously it needs to be authentication aware with either a filter or an event handler for authentication being capable of triggering the appropriate events and views. But apart from that special case, what kind of complex navigational logic is required? Most commonly it is things like the business rules that drive multi-screen wizards and complex checkout processes (if account in good standing show PO screen else show credit card screen – if credit score over 720 recommend payment plan else request payment in full, etc.). But I would argue that (a) stateless event based controllers are not the most elegant solution to this problem (read up on Seaside, a Smalltalk continuation server to get an idea of what I’m talking about) and (b) these kind of complex orchestration rules need to be part of the model. It is bad enough writing them once without having to create a different implementation for every mode you support. Typically these will either be folded in to the existing service layer or will be added as a separate orchestration layer/facade to the service layer.

I’m still really thinking this through, but does anyone have good examples of complex navigational logic that SHOULD definitely stay in the controller that isn’t tied to authentication (which is a little different between say HTML requests and web service calls)?

Calling Views
Then of course the final thing that the controller has to do is to make sure that all of the necessary data is passed to all of the necessary views to build up the page that in turn is returned to the clients browser on the completion of the request.

So, it seems to me at first blush that one of the main things that implicit invocation frameworks are particularly good for (more complex navigational logic) is something that we should probably be removing from the controller to be replaced by a more sophisticated session aware state machine as part of the model so it is easier to program complex logic and so that the logic is somewhere that it can be accessed by all authenticated calls – whether from HTML, AJAX, Flex or web service calls. But if we remove that from the controller, is the current approach to controllers the optimum one? (And yes, this is a genuine, not a rhetorical question.)