I was reading the J2EE design patterns and while going through the Data Access Object pattern I didn't see much difference between the DAO and a session bean that accesses a DB and exposes some methods to get the information.
Can someone point out some differences?
thats true hector.. its more an implementation issue here.
Istead of making use of Session beans directly interacting with DB operations, it is DAO who does all that. And these DAO can be used by multiple entities like Entity or Session or other Servlets..
I have actually been preaching this to some of my clients, so this is a good question, one that they ask all the time.
The DAO pattern is simply a way of abstracting the database away from other components of your system, ie: Session Beans, BMP Entity Beans, Servlets, etc. The big advantage for the DAO, is the ability to move the Database access around to other components without rewriting major portions of your application.
Say you have a Session Bean or an BMP Entity bean on your application server and for what ever reason you find that the response time you are getting simply sucks, and your users are complaining, but you find that if you embed the SQL logic in the servlet or JSP it improves the performance by 10 fold. Well instead of cutting and pasting the SQL code into the client side, you can just instatiate the DAO object instead which is the same object that the entity or session bean was calling, there for 0 duplication of code.
Hope this clarifies the use of the DAO objects.
So do you recommend placing the dao object behind a session layer or just accessing directly from the jsp or servlet?
Also, should the dao return value objects that something else operates on and subsequently returns for updates or should it implement business methods to perform operations on behalf of the caller? For example..
Client gets Person object from dao and updates middle initial and gives back to dao for updating
Client calls method on dao to update middle name and dao executes sql to directly modify db.
Depending on the application, I will place the DAO in any of the layers that makes sense for the appliacation. That sounds pretty vague, but I am not a purist, so just because you use an application server I don't preaching putting everything in the application server layer, but what makes sense as far as performance is concerned. If I need to access the database directly for some reason in the jsp or servlet level i will use the DAO to do that, this would be the same DAO that say one of my entity or session beans are using, therefore I am not reproducing code, or if I change the database access, I am simply changing the DAO and not having to update code in several places. This happens very rarely but in some instances it is neccessary.
All my DAO's use the Value/Object Pattern to pass data back and forth, this is the same Value/Object that the EJB or JSP or Servlet uses, thus keeping the whole interface consistent, and moving DAO's from one part of the application to another part does not require a total re-write or reproduction of code.
I on the other hand do not put any business logic on the DAO level, it is simply store, load, create, remove. I do how ever use the Value/Object's to perform simple business logic, for example self data checks, lengths, type checking, etc.
As far as your examples if I am reading them correctly I would choose the first one.
Hope this helps.
Thanks a lot for your comment.
I maily work with WebSphere app server. If I use a DAO object , say in my servlets, instead of a session EJB. Do I still get the load-balancing, connection-pooling benefits inherent in EJB's by default. While I'm not an expert in WebSphere, I believe some of these advantages can not be taken for granted in all app servers if you don't use EJB's.
I understand the performance part and I believe that is mainly because a call to an EJB is a potentially remote call and a DAO object does not have to. Is that the main reason behind the performance problem or are there other reasons?
Thanks for your help.
If we use DAO istead of putting same code in Session EJB
means we are seprating DAO code (DATA ACCESS CODE) from business code.
So at any given point if we need to change dao we no need to compile EJB for that. We can do it freely.
The Pet Store is using same concept. This you can see in