Re: Keeping Actions clean - separating actions from business mode l from persistence
Mahesh Joshi wrote: I have always wondered where is the best place to do connection management with the dataStore. Should the business Logic do connectionManagement (e.g. opening a connection (via a connection pool or otherwise)) or should that be the responsibility of the persistence layer. Doing it in the latter(PersistenceLayer) frees up the BusinessLayer of connection Mgt code. If you are implementing connectionpool, the overhead is the time to return the connection to the pool and get it back. The iBATIS DAO splits the difference and makes transaction management part of the logical DAO API. So you can specify different connection mechanisms at instantiation, and the implementating code does not need to know the details. The DAO implementation can just call high-level methods like startTransaction, commitTransaction, or rollbackTrnasction. This strategy limits what the implementaton needs to know about the connection management, but still lets the business logic determine what constitutes a transaction (which is often a business decision). -Ted. -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping Actions clean - separating actions from business mode l from persistence
Would it be possible or at least usefull if the SQL objects in that example be used for the Form Beans and for the forms (using XForms). That would really cut don't the amount of work to a minimum Mike |-+ | | Ted Husted | | | [EMAIL PROTECTED]| | | g | | || | | 11/10/2003 11:13 | | | AM | | | Please respond to| | | Struts Users| | | Mailing List| |-+ --| | | | To: Struts Users Mailing List [EMAIL PROTECTED] | | cc: | | Subject: Re: Keeping Actions clean - separating actions from business mode l from persistence | --| Mahesh Joshi wrote: I have always wondered where is the best place to do connection management with the dataStore. Should the business Logic do connectionManagement (e.g. opening a connection (via a connection pool or otherwise)) or should that be the responsibility of the persistence layer. Doing it in the latter(PersistenceLayer) frees up the BusinessLayer of connection Mgt code. If you are implementing connectionpool, the overhead is the time to return the connection to the pool and get it back. The iBATIS DAO splits the difference and makes transaction management part of the logical DAO API. So you can specify different connection mechanisms at instantiation, and the implementating code does not need to know the details. The DAO implementation can just call high-level methods like startTransaction, commitTransaction, or rollbackTrnasction. This strategy limits what the implementaton needs to know about the connection management, but still lets the business logic determine what constitutes a transaction (which is often a business decision). -Ted. -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information in this message is confidential and may be legally privileged. It is intended solely for the addressee; access to this email by anyone else is unauthorised. If you are not the intended recipient: (1) you are kindly requested to return a copy of this message to the sender indicating that you have received it in error, and to destroy the received copy; and (2) any disclosure or distribution of this message, as well as any action taken or omitted to be taken in reliance on its content, is prohibited and may be unlawful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping Actions clean - separating actions from business mode l from persistence
Allow maybe have a couple of generic actions that can save/retrieve and list these objects instead of having to write a action for each form. ie : instead of have to write a form bean/jsp page/edit action/search action/delete action etc.. you just create the xml sql object with some extra details like the search field/edit fields etc. and in you pageflows link the object to the correct type of action like edit/add/search and as these are standard action you do not need to code them? Mike |-+ | | Ted Husted | | | [EMAIL PROTECTED]| | | g | | || | | 11/10/2003 11:13 | | | AM | | | Please respond to| | | Struts Users| | | Mailing List| |-+ --| | | | To: Struts Users Mailing List [EMAIL PROTECTED] | | cc: | | Subject: Re: Keeping Actions clean - separating actions from business mode l from persistence | --| Mahesh Joshi wrote: I have always wondered where is the best place to do connection management with the dataStore. Should the business Logic do connectionManagement (e.g. opening a connection (via a connection pool or otherwise)) or should that be the responsibility of the persistence layer. Doing it in the latter(PersistenceLayer) frees up the BusinessLayer of connection Mgt code. If you are implementing connectionpool, the overhead is the time to return the connection to the pool and get it back. The iBATIS DAO splits the difference and makes transaction management part of the logical DAO API. So you can specify different connection mechanisms at instantiation, and the implementating code does not need to know the details. The DAO implementation can just call high-level methods like startTransaction, commitTransaction, or rollbackTrnasction. This strategy limits what the implementaton needs to know about the connection management, but still lets the business logic determine what constitutes a transaction (which is often a business decision). -Ted. -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information in this message is confidential and may be legally privileged. It is intended solely for the addressee; access to this email by anyone else is unauthorised. If you are not the intended recipient: (1) you are kindly requested to return a copy of this message to the sender indicating that you have received it in error, and to destroy the received copy; and (2) any disclosure or distribution of this message, as well as any action taken or omitted to be taken in reliance on its content, is prohibited and may be unlawful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Keeping Actions clean - separating actions from business mode l from persistence
Hi I have generally have done the following: In the Action: Use a DTO(data transfer object) to transform the ActionForm to a business layer data object Instantiate the business logic class of interest Call a method on the business logic passing the DTO object Depending on the status returned, do the appropriate actionForward call in the action. The action is a client of the business logic. (in case I am not using Struts, but vanilla Servlets, the Servlet replaces the action. the rest till applies). In the Business logic Layer: Apply the necessary business rules. In case of Database persistence, call the persistence manager. ask the persistence manager to persist the data. The business logic shouldn't care how the data is persisted. The standard persistence methods (create, save, findByPrimaryKey,remove,findBy...) are exposed to the Business Logic. The BusinessLogic passes to the Persistence layer objects in the businessdomain (e.g. standard data objects). Primary Keys are encapsulated in a PK class. In the persistence layer store to the datastore by the method of choice (JDBC/any other engine etc.) do the necessary transformation on business data as required by the persistence store. do the reverse when retrieving data from the persistence store. The persistence manager contains the actual classes that know how to store and retrieve data to the persistent store. I have always wondered where is the best place to do connection management with the dataStore. Should the business Logic do connectionManagement (e.g. opening a connection (via a connection pool or otherwise)) or should that be the responsibility of the persistence layer. Doing it in the latter(PersistenceLayer) frees up the BusinessLayer of connection Mgt code. If you are implementing connectionpool, the overhead is the time to return the connection to the pool and get it back. Thoughts are welcome! Mahesh -- Mahesh Joshi W- 408-543-7214 M- 408-829-8051 [EMAIL PROTECTED] -Original Message- From: Sasha Borodin [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 5:33 PM To: Struts Users Mailing List Subject: Re: Keeping Actions clean - separating actions from business model from persistence Matt, thanks for your quick feedback. I use my own framework because I don't know any better. public abstract class DaoManager { public abstract IRecordDao createDao(Connection conn, String daoClassName) throws DaoException; Which tier calls your DaoManager? It seems from your code that the caller of DaoManager is responsible to knowing the database configuration information, as well as the implementing DAO class. Is it the Action? In other words, who orchestrates the interaction of business and dao classes? Does the action instantiate a business class and populate it from your ActionForm, then get a dao instance from a factory, and pass it the business class? Or is there another pattern to this? Thanks. Matt -Sasha - Original Message - From: Sasha Borodin [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, October 10, 2003 6:44 PM Subject: Keeping Actions clean - separating actions from business modelfrom persistence Ted, Matt, Joe, and all the other helpful folks that chimed in earlier on persistence mechanisms: In trying to keep with best practices, I've managed to remove all model related code (business logic, and persistence) out of the Actions' execute() method. Now I'd like to take it one step further and decouple the business model classes from the implementing persistence technology (btw, settled on OJB for now :). From Joe's post, it seems like the DAO pattern is called for to accomplish this. My (slightly off topic) question is this: who develops their own DAO framework (like the dao and dao factory interfaces), and who uses a 3rd party framework (like iBATIS's Database Layer) and why? There was something mentioned about the discovery of the persistence mechanism as well... Any references to webpages/books would be appreciated. BTW, I've been shamelessly posting to this list questions that are probably better directed elsewhere. What would be a more appropriate list? Thank you, -Sasha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional