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.
Josh On 6/4/07, Al Sutton <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 04 June 2007 10:53 To: user@struts.apache.org 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 --> xxxxAction.java(POJO) --> xxxxHelper.java --> HibernateUtil.java --> DB Wherein xxxxAction.java will do the delegation to Helper class. xxxxHelper.java will contain the autual business logic. HibernateUtil.java 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
