struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hookom, Jacob" <Jacob.Hoo...@redline.mckhboc.com>
Subject RE: Theoretical debate
Date Fri, 18 Jun 2004 14:09:48 GMT
For me, it's more so the same argument for changes in EJB 3.0 -- which will
just allow you to use POJO objects for persistence and transactions as
provided by the framework itself.  People argue that EJB is too complex and
doing simple operations takes 6 classes when other frameworks like Hibernate
will work with what you've got for objects.

I don't think it's an issue of abstraction, I can create all the POJO
facades I want until my fingers bleed in order to create separation between
my view/front controller and my application logic, all non-framework
specific of course.

In summary, EJB 3.0 and JSF are pushing to accommodate your existing
objects. IMHO, if I'm spending more time writing adapter code for the Struts
framework then spending time on my core business objects I have to write
anyways, then maybe it's good too look at alternative frameworks.

-----Original Message-----
From: Frank Zammetti [mailto:fzammett@hotmail.com] 
Sent: Friday, June 18, 2004 8:37 AM
To: user@struts.apache.org
Subject: RE: Theoretical debate

I know what your saying, it's the way I do things as well, doing very little

work in the Actions aside from tossing values around and calling subordinate

classes to do the real work.

But doesn't that in a sense support the idea of an application being 
services cobbled together?  What I mean is that the Struts portion of your 
application is really what is forming the application, if by application we 
mean the coherent whole set of pages that make up a larger system.  In a 
sense, if you have that ShoppingCart object without it's methods, let's say 
as an EJB, on it's own it's not an application, it's when you make use of it

from an Action that it becomes part of an application.

Think of it this way... If you have a collection of EJB's that you call your

"application", I would argue that's not correct, the application is really 
only formed when you have a layer above it, maybe a bunch of Struts Actions,

that call on the services of those EJB's to form a whole application.

In that mindset, I can see some logic to saying something like Crysalis is 
on a better path because your simplifying things a bit by essentially 
removing a layer.  I think we're all conditioned to think that ADDING layers

of abstaction is a good thing, but I wonder if that's not in a great many 
cases just added extra layers of complexity that we don't really need.

That's why I made that statement about services.  I mean, the whole Web 
Services movement, when taken to it's logical conclusion, tells us that we 
should be building applications by cobbling together a number of 
losely-coupled service requests, that taken together form a larger 
application.  That's kind of the whole point of WS.

Also, please no one get the idea that I'm saying Struts is anything but 
good, or that I'm saying we shouldn't be doing things the way we are doing 
them now.  My point in starting this thread was just to point what I thought

was an interesting way to look at things that I hadn't considered before, at

least not precisely.  If anything, much of the responses I've read have 
reinforced my belief that what we're doing now in Struts is generally pretty

good.  I am a big believer in the services model of development, have been 
for a number of years now (although I'm not so sure the current forms of 
this methodology are spot on just yet), so discussions of things like this 
are always of interest to me.

Frank

>From: Hubert Rabago <jakartauser@yahoo.com>
>Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
>To: Struts Users Mailing List <user@struts.apache.org>
>Subject: RE: Theoretical debate
>Date: Thu, 17 Jun 2004 13:29:27 -0700 (PDT)
>
>
>  > From: Frank Zammetti [mailto:fzammett@hotmail.com]
>  > Most likely you would have a ShoppingCart class with a number of 
>methods
>in it,
>  > things like addItem(), removeItem(), totalPrice(), etc.
>
>I follow this design on my applications, on the *business logic* tier.
>On that tier (whether I implement it as EJBs or POJOs), I would have an
>actual business object that would have these methods.
>I tend to look at Struts as a necessary add-on to the application to give
>it a web front end.
>To me, my web application isn't "a collection of services that are executed
>to form a coherent larger application", rather it's just an interface
>to the actual application that runs on the server.
>
>
>  --- "Hookom, Jacob" <Jacob.Hookom@redline.mckhboc.com> wrote:
>  > With Struts, I have to create an ActionForm objects (can't just use a
>  > business object I already have), and then create separate Action 
>objects
>to
>
>Because of the way I view my app, I have no problem separating my view of 
>the
>objects in my interface and my app's business objects.  I fully understand
>the need for separate ActionForm objects (users work with untyped string
>values, my business tier works with typed values, the Action object goes in
>between).  Still, I don't like having to create string-ified counterparts 
>of
>my business objects.  That's how the FormDef project began (
>http://www.rabago.net/struts/formdef and http://formdef.dev.java.net/ ).
>
>I haven't tried JSF yet, but I don't think I want my business tier objects
>"contaminated" with presentation-tier specifics, such as the callback 
>methods
>JSF needs on their managed beans.
>
>  >
>  > Any thoughts?
>  >
>  > Frank
>  >
>
>
>Hubert
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Mail is new and improved - Check it out!
>http://promotions.yahoo.com/new_mail
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/


---------------------------------------------------------------------
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


Mime
View raw message