On 10/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> You may ask now what's the place for HttpServletRequest and its company. I
> think its natural place is inside the document itself, hidden inside its
> code, so that the interface is independent from the use of servlet
> technology. In fact HttpServletRequest is a relevant part of the status
> (current requests, session objects, etc.) but the status must be
> "extracted" from the request.
I would tend to agree. An easy mistake to make is to start porgramming
~with~ a framework instead of *into* a framework.This is not only true
of web frameworks but GUI grameworks, like VB. In fact, McConnel tells
a story in Code Conplete of how he used to add a "commit" method to
all his VB forms to help separate th model from the view.
In my own work, we've been bundling up the input we need from the
presentation layer into a context and shipping it up to the model. The
bundle includes items like a "user profile", which in turn includes
the locale and roles, so we can localize and authorize outside the
view. When the context returns, the business transaction, or
transactions, have succeeded or not, and we can disburse any messages
or alter the page flow based on the outcome.
Something like this.
IViewHelper h = executeRead ("SaveB");
if (h.isNominal()) ...
Although it not apparent in this snippet, we are using the equivalent
of a DynaBean as a data transfer object. We send all the input needed
by the transaction up to the model at once. Let the model do its job,
and then flow according to the outcome (isNominal).
IMHO, most presentation frameworks are trying to way too much of the
work. I'm reminded of Boxer from George Orwell's Animal Farm. Every
time the Pigs wanted something, Boxer would say "I will work harder."
Until one day, loyal Boxer collasped.
Much of what we want to do with Struts (or WebWork, or Spring MVC, or
JSF) could be done outside of the presentation layer, or at least a
specific presentation layer. If you see the presentation layer as a
place where we do markup and just the markup, then DTOs become very
useful. The HTTP request sent by the browser agent is a DTO.
The question is whether we want to stop transfering the data when we
get to the servlet (or filter or Action), or continue to transfer the
data on to the model. If we stop at the Action layer, and start
making model calls there, we eliminate a transfer, but we embed
business logic into the presentation layer. If we continue on, we need
to hand-off to yet-another DTO, but we can cleanly separate view from
model. There are benefits and side effects either way. Your Mileage
May Vary.
-- HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
