Like a lot of popular anti-patterns the scattered controller stems from the naive implementation of a seemingly obvious abstraction. The reasoning goes like this: Web-Apps show some html-page, each user event (http-request) triggers an action which, in turn, results in an event determining the next state which is either an action or a an html-page transferred back to the user's browser. So, use the old recipe for desaster: Make each noun of your problem description a class, let the resulting "state-machine" be "declaratively" defined using obscure tables or, more fashionable, xml (ok, luckily, xml is not that fashionable anymore). - And voila, you did it. You've polluted your whole controller with a verbose, scattered "state-machine", the internal workings of which are distributed across a host of artifacts: page-template, action-classes, state-machine-spec, events. And most of the time, all you want to do is: Just call a method and display the results ...
Struts apps are particularly notorious for this Anti-Pattern. If you want to know just how complicated you can make the good old library-search scattering your event-urls not only throughout jsp, java-code and struts-config but also through a spring context, see this ibm-dev-works article
No comments:
Post a Comment