Link Details

This post is a follow up to the post on "DAO Design Problems". Here is the link for the first text

http://www.dzone.com/links/dao_design_problems.html

Isn't this why we have IoC/DI and libraries like Spring? So we don't have to keep writing DAO Managers? All the problems mentioned are already solved and, IMHO, a lot better with Spring. iBatis used to have a small DAO manage API but dropped it. The DAO Manager factory pattern just isn't used anymore.

As far as transactions leaking into your service layer, that's ok because in the real world transactions must be maintained across multiple DAOs. I'm not voting this down because the article is well written. But I'm not voting it up because I don't agree with the content. :)

As far as transaction demarcation I agree. But:


Declarative transaction demarcation, like Springs "AOP" transaction proxy, does not solve the problem of lazy connection opening. The DAO Manager can.

In fact, if you inject a connection directly into a DAO, and that DAO into a Domain Component, you may well open a connection way before it is ever used. Perhaps it doesn't even need to be used, because the validation code in the Domain Component fails. But you have still opened it because it was injected into the DAO, which was injected into the Domain Component.


Declarative transaction demarcation does not solve the "Where are all the DAO's?" problem. A DAO Manager can serve as a single point of access to all DAO's in your application. This eases reuse across large projects where you don't know if a DAO already exists for your particular purpose.


In addition, by rolling a DAO Manager yourself your code is independent of Spring or any framework that provides this kind of mechanism. Granted, this is only useful if you ever
plan to migrate from Spring to something else.

BTW:

I am the developer of Butterfly Container, a Java dependency injection container, and Butterfly Persistence, a Java persistence API, so I have given a lot of thought to these problems. Of course I want the API's to solve these problems if possible. But I have a hard time figuring out how lazy opening of a connection is possible, if DAO's that need the connection injected are not also lazily obtained (meaning NOT injected). This is possible with the DAO Manager.

The only solution to the lazy obtaining of a connection I can think of, is an intelligent connection pool, where the connection proxy doesn't obtain the real connection from the pool until a method is actually called on the connection proxy that needs it. That would
be truly lazy connection opening. I think I'll implement this in the connection pool shipping with Butterfly Persistence in the future.

I read through your article and was really impressed. But I had a problem when I implemented it. Let me explaing my scenario: I am getting a DAO from the DAOManager. As you have explained, I am passing the connection to the DAO object from the DAOManager when it is instantiated and returned to the callee. I call my DAO function and it works fine. However, when I call the same DAO again in the code, since the DAOManager already has the dao instance present just returns the instance of it. Now when I call the DAO functions, I am getting a Connection is closed exception because the previous run of the DAO function utitlized the connection object and closed it. So, accessing the same DAO again with DAO manager will be holding that stale connection. Let me know what I am doing wrong in my implementation of the DAOManager. Thanks.
,