> If the data access objects completely encapsulate
> the connection stuff,
> how does the business object wrap two calls to the
> data access layer in
> one transaction? Take for example the well-worn
> credit and debit
> financial transaction. Would you wrap that up into
> one data access
> object and say OK, we've got two operations rolled
> into one and we can't
> seperate them and re-use them, but that's necessary
> for a transaction?
>
> On the other hand, if the data access objects are
> handed the connection
> by the business object, or if the connection came
> from the struts
> connection pool, then the transaction could be
> handled easily I know. Am
> I chasing a Holy Grail here?
>
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]>
