struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Vickery" <>
Subject Re: Struts 2 Application Approach.
Date Mon, 04 Jun 2007 15:38:12 GMT
Where do your domain classes fit into your structure?  I suggest
thinking about whether you need those "helper" classes (I'm assuming
this is something like a Service Layer) or whether the logic that you
are planning on putting in the "helper" classes would be better placed
in your domain classes.  If you are planning multiple, non-Struts 2
powered front ends, then a Service layer would certainly help you
along.  However, if you are not planning on doing that just yet, I
think you might find it a lot of work to correctly decide on whether
functionality belongs in the domain, the helper classes (service?) or
the action classes.  This is work that you can save yourself from
doing now, or worse, re-doing later, if you are not yet in the process
of implementing multiple front ends.


On 6/4/07, Al Sutton <> wrote:
> My recommendation would be to keep the separation, that way if you wish to
> add further front-ends (such as SOAP, Message Queues, etc., etc.) you can
> construct the necessary equivalents to the Action objects for those front
> ends and still re-use the business logic in the Helper classes.
> -----Original Message-----
> From:
> []
> Sent: 04 June 2007 10:53
> To:
> Subject: Struts 2 Application Approach.
> Hi,
> I am a newbie to struts2.
> I am planning to use Struts2 and hibernate in my project.
> Below is my application flow.
> xxxx.jsp --> --> -->
> --> DB
> Wherein
> will do the delegation to Helper class.
> will contain the autual business logic.
> will contain the logic to persist the data in db.
> Should i need the separation of Action and Helper class? Or can i have the
> business logic in Action class itself?
> Kindly let me know which one is the best approach.Otherwise kindly let me
> suggest some other best practices.
> Thanks & Regards
> Bala
> This email is confidential. If you are not the addressee tell the sender
> immediately and destroy this email
> without using, sending or storing it. Emails are not secure and may suffer
> errors, viruses, delay,
> interception and amendment. Standard Chartered PLC and subsidiaries
> ("SCGroup") do not accept liability for
> damage caused by this email and may monitor email traffic.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message