I agree with this.
I tend to find myself passing parameters to business services rather than
DTOs.

I do it for simplicity.  If i use an ActionForm then you either have to add
things like getNumberAsInt as getNumber returns a string, or do the integer
parsing in the action.  You then have to retrieve stuff from the ActionForm
bean, and put it into

So, it seems pretty much pointless putting stuff into DTOs to then take them
out in the service/DAO.

Another potential "bad practice" i tend to use is to merge DAOs with
Business Objects.  I dont see the need for separate objects, especially when
using OJB you can just create a BaseBusinessObject that includes most of the
DAO code, and extend this.  I also tend to double these up as DTOs where i
need to use them.

Daniel.

> -----Original Message-----
> From: Frank Zammetti [mailto:[EMAIL PROTECTED]
> Sent: 18 June 2004 14:43
> To: [EMAIL PROTECTED]
> Subject: RE: Theoretical debate
>
>
> You know, kind of off-topic, but you remind me of a conversation
> I had with
> someone at work here, maybe you guys would have some input...
>
> I know what various patterns tell us we should do, but in practice... you
> guys of course have your ActionForms that transfer data from the
> view to the
> control layer... do you then have Data Transfer Objects, or Value
> Objects,
> or whatever terms you want to use, to hand off to your model layer?
>
> In other words, do you get data IN via ActionForm to an Action, then
> transfer all that data to another Data Transfer Object, then pass
> that off
> to some subordinate class to do the actual processing?
>
> I ask because most of the Struts apps I've seen don't bother with
> the DTO's,
> they just pass the ActionForm to the subordinate classes, or else
> pass them
> as parameters.  It seems that regardless of what literature is
> telling is we
> should do, in practice (GENERALLY), people don't bother with the DTO's.
>
> Have I just looked at the wrong apps?  What are most people doing in this
> regard?
>
> Frank
>
> >From: "Brian Lee" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: RE: Theoretical debate
> >Date: Thu, 17 Jun 2004 16:54:26 -0400
> >
> >I think struts' concept of separating your actions from your data is
> >admirable and should be followed. The concept of your value/transfer
> >objects (basically the form) also having business logic sounds
> acceptable
> >at first but rapidly becomes a nightmare when you try to use the same
> >value/transfer objects in multiple processes.
> >
> >I think it's a generally accepted practice that separating data
> from logic
> >is a "Good Thing"(tm).
> >
> >BAL
> >
> >>From: "Hookom, Jacob" <[EMAIL PROTECTED]>
> >>To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> >>Subject: RE: Theoretical debate
> >>Date: Thu, 17 Jun 2004 14:57:31 -0500
> >>
> >>I completely agree with what Crysalis is trying to push, also a
> framework
> >>called VRaptor (vraptor.org) also pushes the same idea of
> moving away from
> >>the procedural weight that Struts promotes.
> >>
> >>Look at JSF, do you have actions? No, JSF just updates your
> POJO beans and
> >>calls methods on them.  Why have an ActionForm or have to create all of
> >>these Actions that are simply getter/setter adapters?  Please
> don't be too
> >>quick to retort to my supposed anti-struts mindset, but there are other
> >>frameworks out there that allow direct interaction with my business
> >>objects
> >>and don't require a heck of a lot of framework specific coding.
> >>
> >>---
> >>
> >>Example:
> >>To have a multi-page form with JSF, I just create a bean that sits in
> >>Session scope that has a series of getters and setters.  JSF will also
> >>allow
> >>me to pre-set relationships to other objects at creation time.
> Then, when
> >>I'm ready to submit the multi-page form, I just put in the jsp
> >>#{myFormBean.submit}.  No action mappings, only a managed bean entry.
> >>
> >>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
> >>manipulate that ActionForm.
> >>
> >>---
> >>
> >>-Jacob Hookom
> >>
> >>-----Original Message-----
> >>From: Frank Zammetti [mailto:[EMAIL PROTECTED]
> >>Sent: Thursday, June 17, 2004 2:29 PM
> >>To: [EMAIL PROTECTED]
> >>Subject: Theoretical debate
> >>
> >>Last night I was Googling for something and I stumbled across
> the Crysalis
> >>framework.  I was actualyl intrigued by the underlying premise
> of it and I
> >>wanted to see what others thought about it.
> >>
> >>In a nutshell and in my own words, Crysalis
> >>(http://chrysalis.sourceforge.net/) has the underlying idea
> that when you
> >>develop in most MVC frameworks, Struts chief among them, you
> are actually
> >>doing something unnatural and in a way at odds with basic OOP design.
> >>
> >>Think about a shopping cart example... If you were going to
> write that in
> >>straight Java, not for the web or anything, how would you model
> it?  Most
> >>likely you would have a ShoppingCart class with a number of
> methods in it,
> >>things like addItem(), removeItem(), totalPrice(), etc.
> >>
> >>In Struts, although you aren't FORCED to, what you GENERALLY do
> is create
> >>three different Action classes like addItemAction, removeItemAction and
> >>totalPriceAction, and each is called in response to a form submission.
> >>
> >>But isn't it kind of odd that your object model isn't following what you
> >>probably think in your head is the right way, i.e., one class with
> >>multiple
> >>related methods?  Proper encapsulation and all that jazz, right?
> >>
> >>Well, Crysalis does just that.  It's controller elements are
> regular Java
> >>classes with multiple methods.  What you wind up with is something that
> >>resembles Remote Procedure Calls instead of numerous servlets as
> >>controllers.
> >>
> >>In other words, you would create the ShoppingCart object just as I
> >>described
> >>
> >>above, with all three methods.  Then, when you submit a form,
> the action
> >>is
> >>something along the lines of "ShoppingCart.addItem.cmd".
> ShoppingCart is
> >>the class to execute, addItem the method and cmd is a suffix to
> direct the
> >>request, just like extensions in your Struts apps map requests to
> >>ActionServlet.
> >>
> >>The elements of the submitted form are treated as the parameters of the
> >>method being called, making it rather elegant.
> >>
> >>I haven't gotten into any real detail on Crysalis, but I was
> interested in
> >>getting other peoples' thoughts on the underlying principal (which I
> >>*THINK*
> >>
> >>I've stated properly!).  It was rather interesting to me
> because I'd never
> >>reall considered looking at it that way, and certainly it's not the way
> >>you
> >>typically approach a Struts-based application.  It was also
> interesting to
> >>me because I've for about four years now been preaching here at
> work that
> >>we
> >>
> >>should write our applications as a collection of services that are
> >>executed
> >>to form a coherent larger application, which is very much along
> the lines
> >>of
> >>
> >>this (so I guess I actually HAVE looked at it this way in a
> sense, but not
> >>exactly).
> >>
> >>Any thoughts?
> >>
> >>Frank
> >>
> >>_________________________________________________________________
> >>Watch the online reality show Mixed Messages with a friend and enter to
> >>win
> >>a trip to NY
> >>http://www.msnmessenger-download.click-url.com/go/onm00200497ave
/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]
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>

_________________________________________________________________
Get fast, reliable Internet access with MSN 9 Dial-up – now 3 months FREE!
http://join.msn.click-url.com/go/onm00200361ave/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]

Reply via email to