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]>
