Hi Mike, I saw one good example in Chapter8(Data Access Patterns) of Professional JSP Site Design. This example has very clear design on using action object, business logic object, data access object, and the entity object. You can download the code in http://www.wrox.com/ACON10.asp?WROXEMPTOKEN=34282Z8saK1uBNIvHOfBhvowLQ&type= &order=1&subject=0
Hopefully this can help you somehow. Regards, Sophia -----Original Message----- From: Jerome Josephraj [mailto:[EMAIL PROTECTED]] Sent: Friday, February 08, 2002 6:40 AM To: Struts Users Mailing List Subject: RE: actions and business logic Mike, It's better to keep all your business logic in a separate layer say Business Services layer which is independent of your action layer. This helps you in decoupling actions and business rules. Ideally checking for rules, permissions should go in Business services layer but it's good to have these in a separate objects and access these objects in appropriate places in Business layer. This gives the flexibility of adding/removing permissions, roles at it's own convenience. Hope all your lookups, permission roles are in a database. This will greatly help in skiving any future business rules changes as most of the time these rules are capricious and arbitrary (At least in the project which I am working on) Cheers, Jerome. -----Original Message----- From: Mike Dewhirst [mailto:[EMAIL PROTECTED]] Sent: 08 February 2002 14:09 To: 'Struts Users Mailing List' Subject: actions and business logic I wanted to clarify something. We are in the design stages of our project and have to make a decision what role do Actions play in the framework. We are using JRF for the database tier, and Struts for presentation one. I want to get a clear-cut answer to decide how much business logic (such as preparing data - determined by permissions, busines rules, etc.) we have in the Actions. My understanding (from previous Struts projects) is that Actions are mainly for processing the request and passing parameters onto business logic classes. You may, for instance, get a request asking you do create a new business object. The object may require checking of rules, permissions, look-ups, etc. It is my understanding that this should be done in a separate, context independent business object class. Is this correct, or is it ok (in less complex projects) to have most business logic in the Action class? Many thanks in advance for advise! Mike Dewhirst =********************************************************** If you are not the intended recipient, employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination or copying of this communication and its attachments is strictly prohibited. If you have received this communication and its attachments in error, please return the original message and attachments to the sender using the reply facility on e-mail. Internet communications are not secure and therefore the UCLES Group does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of the UCLES Group unless otherwise specifically stated. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses although this does not guarantee that this email is virus free. **********************************************************= _____ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>