RE: actions and business logic
How sure can you be that tomorrow will not lead to a request for a third, fourth,... UI ??? OK XP means code as little as possible too early... but if you have two UI's you should cater for the third, because the second already calls for the isolation-layer. just my 2cents Alexander Jesse -Original Message- From: Keith Bacon [mailto:[EMAIL PROTECTED]] Sent: Freitag, 8. Februar 2002 17:42 To: Struts Users Mailing List Subject: Re: actions and business logic I agree. Is it worthwhile adding a facade layer if you only have 1 or 2 different user interfaces? I can see the value if a change to business logic requires dozens of GUI changes. Also if you are writing a UI for a part of a complex system it's a way of the owners of the system presenting you with a restricted/simplified interface. For workflow some people seem to want to specify it with tags on the jsp, but I prefer (as you say) to do it in the action class. The jsp page is concerned with display/capturing data job not where it's going to or coming from. These insights into how othe people things are fascinating valuable - more please! Keith. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: actions and business logic
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]
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]
Re: actions and business logic
Hi! In my opinion: The Action-objects should handle the workflow, second level validation, security, ... and so on. It makes things much more complicated when you mix up workflow with business logic. So usually I try to use a facade pattern (see design pattern book from gang of 4) for getting a high level abstraction of my business logic and a central access point for my action layer! Additionally reusability and maintenance is also an important factor. By means of a facade pattern you are more fexible if you have to change the business logic. And if there is no bl in your action classes it is easier to change the workflow! Chris. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: actions and business logic
I agree. Is it worthwhile adding a facade layer if you only have 1 or 2 different user interfaces? I can see the value if a change to business logic requires dozens of GUI changes. Also if you are writing a UI for a part of a complex system it's a way of the owners of the system presenting you with a restricted/simplified interface. For workflow some people seem to want to specify it with tags on the jsp, but I prefer (as you say) to do it in the action class. The jsp page is concerned with display/capturing data job not where it's going to or coming from. These insights into how othe people things are fascinating valuable - more please! Keith. --- [EMAIL PROTECTED] wrote: Hi! In my opinion: The Action-objects should handle the workflow, second level validation, security, ... and so on. It makes things much more complicated when you mix up workflow with business logic. So usually I try to use a facade pattern (see design pattern book from gang of 4) for getting a high level abstraction of my business logic and a central access point for my action layer! Additionally reusability and maintenance is also an important factor. By means of a facade pattern you are more fexible if you have to change the business logic. And if there is no bl in your action classes it is easier to change the workflow! Chris. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: actions and business logic
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=34282Z8saK1uBNIvHOfBhvowLQtype= order=1subject=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]
