- Posted by: Pankaj Vij
- Posted on: March 05 2002 14:23 EST
I cant seem to understand the advantages of DAO.
Normally the underlying databases doesnt change so often for most of the projects to warrant the use of DAO.Why not to go for CMPs in such cases ?
DAOs seem to be useful only when dealing with single objects (read single table).Entity beans are too expensive in cross table joins when searching and listing data.Why not JDBC queries in a session bean in such cases ?
I will appreciate very much ; if someone can make me understand what are the scenarios where I can use DAOs if my underlying database isnt gonna change.
Thanks and regards
- DAO/Entity Beans/JDBC queries in session bean by Neeraj Nargund on March 06 2002 16:58 EST
The benefits of this pattern are:
Greater deployment flexibility. Data access objects represent data sources through an interface. The implementation of that interface can be configured at deployment time.
Resource vendor independence. Components that use vendor-specific API to access data resources lock themselves into using that particular vendor. The DAO pattern isolates vendor-specific code where it can be easily replaced.
Resource implementation independence. For example, persistent data store can be implemented by a relational database, an object database, flat files in a filesystem, etc.. The DAO pattern allows designers to focus on the behavior of application objects, and deal with data access mechanisms separately.
Improved extensibility. New resource types are easy to add, requiring only a new DAO implementation for the resource type, plus integration of that class into the existing framework.
The liabilities of this pattern are:
Increased complexity. This pattern adds a level of indirection to data access, increasing the number of objects in the system and making the code slightly less clear.
Thanks for the reply.
But my question is ; if i dont want to change my database implementation ; what advantages do I get from it ?
Tim, you are right when it comes to data access from EJBs but if you want to access the database directly from a servlet (for example), DAOs can be a useful abstraction.
Do lookup the fast lane reader pattern for more info.
Even if you don not want to change you database implementation, remember that you are developing using J2EE, that means that you should always think of scalability and reusability issues. Even if you do not want to change your database today, you or someone else could be needed to change it tomorrow. You know what it will be a mess re-writing all you hard-coded SQL codes scattered all over the code? Yes, you can contradict that we could use CMP instead. The contraversal question: have you ever seen a really LARGE high transactional project using CMP? It works fine for the systems of the "petstore" level, but you'll find out what "surprises" are lying inside your appserver as soon as you'll start using CMP on a large projects. SQL SHOULD never be the same for different databases. When you switch to another database all what you'll receive are numerous locks on all your tables - SQL code should be RE-WRITTEN for each specific database in compliance with its own SQL optimization engine. JDBC drivers cannot do such things for you. You should do manually. Another alternative is to use stored procedures and call from JDBC without caring about all the SQL stuff, because it will the RDBMS server's headache. I find this kind of implementation as the most powerful one and use it currently in my projects in a pair with DAO objects that I use INSTEAD entity beans (Why? Many reasons that could be the topic to a different post).