struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Dewhirst <>
Subject actions and business logic
Date Fri, 08 Feb 2002 14:08:33 GMT
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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message