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
business domain (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 commands, e-mail: [EMAIL PROTECTED]
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
