[Friday] Front Controller pattern sucks

[Michael Jouravlev <jm...@gmail.com>]

Intro
-----

Struts sucks (c) Jason Carreira. Struts implements Front Controller
pattern. ==> Front Controller pattern sucks ==> ASP.NET does not suck
because it uses Page Controller pattern ==> J2EE must have its own
non-sucky Page Controller framework ==> JSF has been born ==> JSF does
not suck!

Meanwhile, Microsoft adds Front Controller support into ASP.NET 2.0
because many ASP.NET developers think that Page Controller sucks ==>
JSF sucks because it is a Page Controller framework too ==> Front
Controller and Page controller patterns suck, JSF and ASP.NET suck too
==> Everything sucks and we all will die.

Umm, my conclusions must be flawed, because everything cannot be
*that* bad. Let's see, it is incorrect to conclude that a pattern
sucks judging by one implementation. It is improper to conclude that
because one pattern sucks, another one does not. Also, as I was told,
JSF is not strictly a Page Controller framework. Anything else? Here,
here, found one (see below).

Struts is not a Front Controller framework
------------------------------------------

After three Margaritas that I had last night, I see it all clearly
now. Either Sun's definition of Front Controller is flawed or Front
Controller is not what I though it was.

Sun defines duties of Controller like this[1]:

"Typically, a controller coordinates with a dispatcher component.
Dispatchers are responsible for view management and navigation. Thus,
a dispatcher chooses the next view for the user and vectors control to
the resource."

So, according to Sun, a dispatcher chooses next view and "vectors
control" to the resource. In Struts terms, dispatcher is an Action.
Works for Struts, eh?

My understanding of Front Controller was that controller *selects* a
command, or a view or a helper. The idea that the controller must
actually *perform a selection* resonates with Microsoft's definion of
Front Controller[2]:

"Front Controller solves the decentralization problem present in Page
Controller by channeling all requests through a single controller. The
controller itself is usually implemented in two parts: a handler and a
hierarchy of commands.

The handler has two responsibilities:
* Retrieve parameters. The handler receives the HTTP Post or Get
request from the Web server and retrieves relevant parameters from the
request.
* Select commands. The handler uses the parameters from the request
first to choose the correct command and then to transfers control to
the command for processing."

See? The handler, which is part of controller, *chooses* the correct
command. This definition seems more appropriate for me. Does this
happen in Struts? No way. In a Struts applicaiton the request already
contains action mapping name, that is, a client sends request to a
specific action! Controller selects nothing, it just performs some
housekeeping tasks like initializing actions and forms. This is it.

Therefore, Struts is based on interceptor pattern, nothing more,
nothing less. COR, introduced in Struts 1.3, is a logical development
of a rather monolythic implementation of this pattern in prior
versions.

I am not an authority on patterns, but it seems to me that Sun
"patched" its definition of Front Controller to match Struts
architecture. Whatever.

Before- and After- actions. Where did this come from?
-----------------------------------------------------

First off, I prefer to call them Before and After instead of Pre and
Post to not mix Post-action with POST request method.

Now, how does Before-After pattern fits Front Controller pattern?
Well, they are orthogonal. Anyone who is saying that Before-After
pattern is an inherent part of Front Controller is lying his ass off.
To me, the Before-After pattern is the very approach that makes people
shout "Struts is abomination!".

Think of it. According to Before-After pattern one JSP page needs two
actions: one to display it for the first time and another to collect
the input. What happens if input is invalid? The page is redisplayed,
now from the After-action. So, two actions perform the same duty:
[re]display a page. Don't even get me started on two different URLs
for the same page. What if input is correct? then After-action usually
displays success page. Now one action handles two pages. This is M:M
relationship, which can be called differently: a nightmare. There is
absolutely nothing intuitive in this pattern. Yuck. (I hope WebWork
does not use this, eh, pattern).

Action as web resource: bring the sanity back
---------------------------------------------

In Struts an action is what a user navigates to from the browser (GET,
load resource). Also, an action is the place where event/command is
sent (POST, manipulate resource). With Struts, browser works with
actions. On the other hand, browser generally works with *resources*
==> an action represents a resource. Resource is an object that can be
displayed or manipulated ==> one action as a proxy for a particular
resource, should render resource's view (forward to JSP page) as well
as accept commands to manipulate the resource.

One resource -> one action -> one or multiple views. Simple.

DispatchAction: event-processing model
--------------------------------------

DispatchAction and its flawors allow to define events and to link
events to handler methods. Now you have it:

* DispatchAction defines a web resource and handles GETs and POSTs
* On GET (load resource) DispatchAction displays an appropriate view
* On POST (called postback event in some *other* frameworks)
DispatchAction invokes appropriate handler and then either:
  - redirects to another action (another resource)
  - forwards to a view (renders this resource's view)
  - redirects to itself (thus rendering a view in a separate request)

The above solution keeps Front Controller pattern (interceptor
pattern, whatever) intact. It provides clean 1:1 relationship between
action's URL, action and resource. It provides clean event model like
in Page Controller frameworks.

Redirection? Session scope? Yes, I do like them. But you don't have to
use them if you don't want to. Use forwarding. From the conceptual
point of view it is still better than Before-After antipattern.

Objections?

[1] Core J2EE Patterns - Front Controller,
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
[2] MSDN, Front Controller Pattern
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/DesFrontController.asp
[3] Service To Worker pattern,
http://livedocs.macromedia.com/jrun/4/Programmers_Guide/designpatterns6.htm#1114513

Michael Jouravlev.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [Friday] Front Controller pattern sucks

[Simon Chappell <si...@gmail.com>]

On 2/2/06, Michael Jouravlev <jm...@gmail.com> wrote:

* snip a bunch of stuff *

> Objections?

More of a comment really. While you may or may not be right about
which framework/buzzword/concept/pattern sucks and how much they suck,
Struts has helped me "git 'er done" without too much pain.

Call me a pragmatist, but "working code trumps everything". Struts
works! I have no argument for or against it sucking or not sucking,
but it does work. And that, ladies and gentlemen, is why Craig will be
forever one of my geek heroes. At the end of the day, my business
users care about whether their promised system is delivered and works.
Period. Full Stop. Buzzwords don't help me process our widgets.
Working code processes widgets.

Just my perspective.

Simon

--
www.simonpeter.org
uab.blogspot.com

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org