Application Controller

Intent: A centralized point for handling screen navigation and flow of an application.

Can anybody explain this pattern? Thanks -- BernardDevaux?

http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html

Actually it is more like an AntiPattern, I don't know where they got the idea that "centralized control" is good.

Either way, how about a quick summary?

It's already available at the referenced URL. But it's just what it it says: a centralized point to control the navigation between screens.

That doesn't go very far in explaining your objection to it. Just that the word "centralized" is always a smell? The URL seems to be saying that it's MVC with a dispatcher added to choose the view, in the context of serving multiple concurrent requests, which doesn't sound very evil. But maybe I'm missing something. That page explains, it does not summarize, and I don't recall hearing of this (Anti)Pattern before. The value of a summary is that it can present your own understanding of something that apparently you are already familiar with. Just directing someone to the URL, which does not have much of a summary, means someone not as familiar as you with the pattern may get an incorrect first impression.

Well, the effort should be on the guys proposing something as a pattern shouldn't it? The ApplicationController (typically in web-based application) basically makes the decision that given a form submission from a previous screen, which is the part of the code that will process it (sometimes with an additional "moving of bytes around" by re-packaging the HttpRequest? object as an AppEvent? object to more closely offer the illusion of non-web, event driven application). And sometimes with a different twist that the part of code that processed the requests, upon the completion of the "update" processing, delegates back again to the application controller that will decide which screen will be displayed next.

To add to the twists, other application frameworks allow you to do ApplicationController in one XML configuration file, rather than in code, so the code now looks clean and nice, but the complexity has moved into the XML.

Basically this kind of works (but nothing to write home about, however) when you have a few screens (maybe below 100). But when you have screens in the hundreds and even in the thousands (in the real world not the PetStore world), centralizing control is not the way to go, you want to decentralize control. This relates to basic principles of modularity that applies to all software engineering artifacts; there's nothing special about web apps. In order to manage complexity, we have basically a handful of basic tools: modularization, decentralizing, abstraction. In no case will centralization make for better management of complexity.

I see. So this is just the polymorphism issue all over again in new garb. It could be decentralized by taking the centralized dispatcher and stuffing it into each request as a self-dispatch, then.

Quick summary: if there are a range of possible responses to a given request, an ApplicationController decides which response to make based on the state of something or other.

Examples: is the user authenticated and authorised to carry out this action? Does a form submission have all required fields filled in and did all values validate successfully? If you choose to dump the user in an "internal server error" page when the db host is unavailable, that's another application controller decision. Anything which affects the choice of view. PoEEA provides the example of a form wizzard where progress is dependent on previous pages being successfully submitted before the next form is displayed but application controller logic is much more widespread than that.

This pattern can merge into FrontController and PageController?. Both have to decide how to respond to a request (with FrontController additionally having to identify the request type). There may or may not be a discrete ApplicationController in a separate class (or classes), but there is always some application controller logic to do.

A ChainOfResponsibility might provide a flexible implementation of ApplicationController. Loosely-coupled request handlers can decide for themselves whether to handle the request. -- NoelDarlow

I am confused whether the verdict is good, bad, or ItDepends on the use of this ?pattern, and for what situations. And is this applicable for WebApplications? not using the JavaPlatform? Does its use enhance / interfere with AjaxWebApplications? And how does it relate, if any, to other patterns Factory, etc, etc

Maybe the top of page can benefit from a summary of applicability.

A general note: EVERY pattern can be an AntiPattern if it is indiscriminately used. ApplicationController is no more an AntiPattern than Factory. Context matters.

More importantly, try reading the entire discussion about the pattern from the author of the pattern. Fowler explains quite clearly (in the book PoEAA, not the website) that any given application can have one or more ApplicationController instances. Maybe you really need just one because you have an insanely complex state machine, where the views are not groupable. More than likely, though, you will have a group of related views, especially if you, as Fowler suggests, have a "wizard" to guide the user through a series of views. For these scenarios, the ApplicationController can help you adhere to the DRY principle when putting logic into your controllers or presenters. -- AlanMcBee