I was just reading Data Access Object pattern. It recommends abstracting the database access logic in a seperate class. The servlet, JSP, Session bean and Entity Bean (BMP) would use this class.
Now if the Data Access Objects are simple classes, understandably they are not managed by the Container.
Hence we need to implement connection pooling and managed transaction across the application.
I am not able to appreciate the use of this. Could someone please throw some light on this.
Thanx a lot
You can still use transactions and connection pooling from DAO by passing the connection object to it. You are just creating a class which is the centralized location for all SQL and Database access. You can have a DAO for each entity or a factory of DAO. This will make the transition from one backend database to other easy. Even programmatically you can access different data sources. You have other advantages of using the DAO to access the Database tables from entity bean as well as Session Facade for the result set of a page. Thus avoiding the duplication of SQL and a common place to look when you need to change the colums or
change the queries.
I have used DAOs on two projects and they are practicle for a few reasons. 1)When using a DAO to do the data access for an EJB, it's easy to test/debug the DAO from your IDE's debugger to make sure it returns the correct data. It's more difficult to debug EJBS. In another project, we used DAOs to do the data access for regular Java classes. It was useful because I worked on the DAOs and got them working while another devleoper worked on the classes that called those DAOs. We put them together when both pieces were finished. It was a good way to break up the development responsibilites.