Hi Robert,
that is more or less what I am aiming to do. I see you don't pass
connections around - at least not across your business to DAO interface.
So from your code snippet, I guess your transaction object gets the
connection and puts it somewhere that the DAOs can find it? Or do you
pass your transaction object into your DAOs via their constructors?
I am going with the struts connection pool so I'm thinking how I can
wrap them up without having to repeat lots of error handling in the
business objects.
Regards
Adam
Robert Taylor wrote:
>Adam, when I first started using DAO in my application,
>I had course grained DAO's that encapsulated transactions.
>They were responsible for managing the transaction boundries
>(getting the connection, committing or rolling back, and then
>releasing the connection). I then found that they were not
>as reusable and they contained a lot of business logic. I started
>thinking, this doesn't make sense. To me, it was more intuitive
>that the DAO should only be responsible for data access and
>the business logic and transaction management should be a layer
>above the DAO. So now, my business objects are responsible for
>managing the transaction (actually they delegate it to another
>module) and DAOs "join" the transaction in progress. The DAO
>become more reusable and are decoupled from the mechanism that
>manages the transaction. So now I have something like the
>following:
>
>ITransaction trans = // get a transaction object
>
>try {
>
> trans.begin();
>
> dao1.insert(dto);
> dto2.setForeignKeyId(dto.getIdentity());
> dto3.setForeignKeyId(dao1.getIdentity());
>
> dao2.insert();
> dao3.insert();
>
>
>} catch (DatastoreException de) {
>
> trans.setRollbackOnly();
> throw new BusinessException(de);
>
>} finally {
>
> trans.end();
>
>}
>
>
>Each DAO joins the transaction (accesses the Connection in the same thread)
>and uses it to perform the necessary data access operation. A nice side
>effect
>is that all the tediousness and complexity involved in managing the
>transaction is
>wrapped up in a simple API and not over multiple DAOs.
>
>Right now, I use straight JDBC but if I decided to use JDO or another
>mechanism for transactions, my business client doesn't change. Just like
>if I change my business logic, my web client (Struts XXXXAction classes)
>don't have to change. I find this provides more cohesion within layers.
>That is, the business objects do business stuff by delegating to data access
>objects and data access objects just access data and tend to deal with
>tables
>that are related.
>
>This is just one way to do it, as Kevin already mentioned, there are other
>ways to skin this cat.
>
>HTH,
>
>robert
>
>
>--
>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]>
