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:[EMAIL PROTECTED] Sent: Friday, June 18, 2004 8:37 AM To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: Struts Users Mailing List <[EMAIL PROTECTED]> >Subject: RE: Theoretical debate >Date: Thu, 17 Jun 2004 13:29:27 -0700 (PDT) > > > > From: Frank Zammetti [mailto:[EMAIL PROTECTED] > > 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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > _________________________________________________________________ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]