You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Ted Husted <hu...@apache.org> on 2003/10/11 12:13:46 UTC
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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Keeping Actions clean - separating actions from business mode l
from persistence
Posted by MB...@cpaglobal.com.
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 |
| | <husted@apache.or|
| | g> |
| | |
| | 11/10/2003 11:13 |
| | AM |
| | Please respond to|
| | "Struts Users |
| | Mailing List" |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Struts Users Mailing List <st...@jakarta.apache.org> |
| 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
********************************************************************************
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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Keeping Actions clean - separating actions from business mode l
from persistence
Posted by MB...@cpaglobal.com.
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 |
| | <husted@apache.or|
| | g> |
| | |
| | 11/10/2003 11:13 |
| | AM |
| | Please respond to|
| | "Struts Users |
| | Mailing List" |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Struts Users Mailing List <st...@jakarta.apache.org> |
| 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
********************************************************************************
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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org