We also use JRF & Struts. We try never to put any business logic in the action object. Action objects call boundary objects and the boundary objects call business logic controller objects. All business logic goes into the controller objects. As you can see, we build our applications based on the Rational Unified Process.
If there is any logic in an application that would need to be done no matter what user interface we used (web, client/server, etc), that logic goes into the controller object. The boundary objects are interfaces between Struts and the business logic. Business Logic Controllers don't know what a form object is because that is Struts specific. The boundary object converts data from the controllers into form objects and form objects back into native data. By building the app this way, changes in business logic don't require changes to the UI and changes in the UI don't require changes to the business logic. All the action objects do is call the boundary objects as needed to get or update data and prepare form beans for the JSP's that view the data. In this message, a controller object is NOT the C in MVC. MVC is all user interface code. Our controllers are business logic code. See Rational's web site for more information on the Rational Unified Process. Jay On Fri, 8 Feb 2002, Mike Dewhirst wrote: > 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. > > **********************************************************= > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
