[OT] Re: What's wrong with DTOs?

["Frank W. Zammetti" <fz...@omnytex.com>]

Only fair to mark this thread OT by now, hope no one minds...

Talking about the view that considers what goes on in Struts Actions to be
part of the view, here's why I don't agree with that perception...

In that view, if I have a webapp and later want to make it a Swing-based
app, I would be throwing away not only the JSPs but also the Actions.  In
fact, all I'd be keeping is the "Model" components, the real business
logic guts of the app.  This is the typical approach taken.

However, in my view, If I have that webapp, I would only throw away the
JSPs, which is what I consider the View, and only the JSPs.  The way I
write apps, the calls to the server made from a browser are either viewed
as events or service requests.  In fact, the whole paradigm is simply
termed Service-Oriented Architecture.  If you view a webapp as a sequence
of pages, then you tend to have trouble doing what I'm saying because the
underlying architecture is a contrary one.

Instead of coding into the Swing app what should happen when a user clicks
a button for instance, what window should be shown perhaps, this decision
is pushed back onto the server.  A normal HTTP request is made that
determines the next window to show.  Now, the difference is that the new
view is not rendered on the server as with JSPs.  Instead, a code is
returned that the Swing code interprets and displays the appropriate
"response".

In this regard, the Swing app is strictly the View.  The Control layer,
still implemented in Struts, remains the same, and has no knowledge that
its now dealing with a Swing app instead of JSPs... the only difference is
that I use the JSPs that an Action forwards to in order to render the code
that the Swing app recognizes.  The JSPs are something like this:

<%="showCustomerEditWindow"%>

Literally, that's it!  Wouldn't even be a scriplet in reality, but I
showed it that way to illustrate what's going on.  This code tells the
Swing code to display a particular window, but it doesn't tell it anything
about what the presentation looks like, that's all up to the Swing code. 
Usually I would have the JSP also send back a serialized version of the
ActionForm so I can have my data too.

Now, it's easy to remove the JSPs if I want to and do this all from the
Actions, it's arguably a superfluous step to go to a JSP.  But, the nice
thing about it is that all I do is change the JSPs in struts-config to not
point to the JSPs that render a browser-based page, but instead points to
the pages that renders the codes the Swing app can make sense of.  In this
way, switching from a web-based app to a Swing-based app, as far as the
code on the server goes, is nothing but changing a config file.  NO code
needs to be touched.

The point I'm trying to make is that if I viewed the Actions, and indeed
all of Struts, as part of the View and not the Control, I'd be throwing a
lot more away than I need to.  I mean, the flow of the application still
exists in Struts, the Swing app is just another way to represent things to
the user.  This is why when we talk about the "webapp" being not only the
JSPs but the Actions and ActionForms, etc., I believe that view leads not
to less work to change, but MORE work, and as such does not represent
"proper" separation or description of MVC (as we know it today at least).

I admit I've never done this in a production environment, but as a
proof-of-concept about 3 years ago I took an existing webapp, a relatively
complex one too, and did exactly what I'm talking about... I threw
together a Swing-based front-end and used it instead of a browser.  It
worked perfectly.

Now, the obvious drawback is performance.  You *do* pay a penalty doing
this vs. a "typical" Swing app where there are no server calls involved. 
Not to mention the question of what's the point??  So, the whole premise
probably doesn't make a whole lot of sense to begin with (switching a
webapp to a Swing app in this fashion I mean).  But it can be done, and by
thinking of what lives in Struts as truly the Control layer, and keeping
that separate from the View and the Model (the model being everything
else, the real "guts" of the app), you have the flexibility to change
presentations without doing more than you really have to, i.e., recoding
the flow of the application.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com

On Tue, October 18, 2005 3:37 pm, Christian Bollmeyer said:
> George.Dinwiddie@wellsfargo.com schrieb:
>
> +1. The first thing I always preach new developers
> on my team is that they should think the entire web
> tier away and replace it (mentally) with a Swing or
> whatever client, without changing anything in the
> subsequent layers, and the application still has to
> work as usual. From an architectural view, the
> entire OO thing is about loose coupling, separation
> of concerns and minimizing dependencies. Now
> MVC - a pattern emerging from its first Xerox in-
> carnation some 25 years ago, originally invented
> for SmallTalk-based rich clients and targeted at
> helping to coordinate keyboard input, 'business logic'
> (as understood back then, mysteriously named 'Model')
> and monitor output in a responsibility-oriented way,
> has since been adapted to different technologies
> including the web. Still, it's strictly about getting
> input and showing things from the Model. Now,
> unlike in the old days, applications are usually
> architecturally somewhat more complex now-
> adays and split into different layers (naming varies).
> Usually, there's at least one layer for the 'business
> logic' (a.k.a the application) and a subsequent one
> for resource access. Both of them are relative long-
> lived compared to the client (web) tier which can
> change every few years, from Struts to JSF or
> whatever, whereas the business logic itself tends
> to stay relatively static (usually the database itself
> is the part with the longest lifespan, database models
> easily reaching the age of 30 or more). There-
> fore, IMHO it's a good idea to keep heed of
> a strict separation of architectural layers
> throughout the entire application, providing
> interfaces like BusinessDelegate or Facade
> to be used by different client implementa-
> tions in a consistent way even in case of
> a complete technology change in the client
> tier. This may possibly require more work
> to keep thing as abstract as possible, but
> I'm quite confident it'll pay some day. And
> that's where DTOs (or ValueObjects, which
> originally were designed to address granu-
> larity issues when dealing with EJB and the
> like) or domain classes come in. I, for once,
> don't want to see *any* web-related stuff in
> my backing layers; no document/view con-
> siderations here. Better leave that ground
> to  the few remaining MFC adepts who still
> think C++ is the one true solution to every-
> thing. MVC, then, was born as a 'client' pattern
> and stays one. YMMV, as always :-)
>
> -- Chris.
>
>>>-----Original Message-----
>>>From: Dave Newton
>>>I'm still not clear on how the entirety of MVC is the V
>>
>>
>> It's not.  MVC is a View Tier pattern, though.  Within the pattern it
>> separates the Model, an abstraction of the business logic, the View,
>> which displays a representation of the Model, and the Controller, which
>> translates user input into requests to the Model.  The point is to bring
>> clarity to the Presentation Layer.  See
>> http://idiacomputing.com/moin/LayeredArchitecture#head-386ccace28b9d5122
>> 1f9ed6fe4dc1c59581ef0b5
>>
>> Many people learning MVC for the first time mistake this presentation
>> layer pattern for an architecture of an entire application.
>>
>>  - George
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


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