I posted a question using DAOs with Seam projects a while back and Christian Bauer replied that he uses DAO layers in some of his projects. According to Rod Johnson in his J2EE w/o EJB book, DAOs are good to use if you have a lot of biz logic and persistence logic that needs to be separated.
In my earlier Seam projects, I did not use a DAO layer (small, simple CRUD systems don't necessarily need the added complexity).
In my current project, we do have a DAO layer implemented by SLSBs. The advantage of having a separate layer for data access is that this layer can be reused in case the project is re-architected (e.g. Seam replaced by Spring).
One of the things I like about Seam is, unlike other frmwks, it does not enforce any particular patterns or layering...
but see, my static methods that do the DAO logic can also be reused if we go from seam to spring. We just stick the static methods in the EJB itself and the DAO layer we had of 44 classes and 44 interfaces above those classes(to encapsulate) basically got deleted.
We do not need to rewrite this code if we switch from seam to spring so DAO's did not buy me anything in that use-case. I just am trying to get a good example I guess where the DAO becomes useful and helps me write less code or maybe helps me write less code at a later date when we need to change, but every case we have been through, I just don't see.
This is kind of like that getters/setters being evil argument(google
getters/setters evil). He makes some good point even though i still use getters/setters myself, though I wish java had a feature to automatically add getters/setters or something.
Dean Hiller wrote on Mar 25, 2010 19:27:
He makes some good point even though i still use getters/setters myself, though I wish java had a feature to automatically add getters/setters or something.
I believe Groovy has this feature (you can see it in one of the groovy Seam distro examples IIRC). The auto-generation of getters/setters and local interfaces for EJB's is something that should have happened a long time ago. Only catch is if you need to apply Hibernate validator annotations, for example. The getters/setters are created dynamically by Groovy (i.e. the methods are not there in the src file).
I have now not used DAO's on the last 3 projects for 2 years now. Instead we add a NamedQuery of findXXByYYY and a static method findXXByYYYY on the same bean that accepts the EntityManager as a parameter.
I have not used DAO's (or @Entities) for several projects now (shocking!). It seem much easier to use JdbcTemplates and return List<Map<String,Object>> from the database (more shocking, specially for me!).
That has significantly reduced our code base and complexity of the system.
Same case for me, no more need to have all those @Entity classes and have to keep them in sync with our database model (or having to adjust the database model so that it is acceptable for JPA/Hibernate...
On 3 projects and 2 years, I don't see the DAO buying anything except more work these days.
Same thing with @Entities here. If they were like Cayenne DataObjects where you an actually write business logic inside your domain model (and therefore avoid the AnemicDomainModel anti-pattern) but, since that is nor permitted or recommended.
thoughts? I just don't get why articles are still being written on DAO's and making them generic, etc. etc. I am having such a hard time finding benefit from them.
I guess the answer is
But then again, I might be very wrong. Maybe this would only help me because of the kind of problems I am needing to solve right here and right now. Who knows?
Adam Bien has a nice post about DAO:
GENERIC CRUD SERVICE AKA DAO - EJB 3.1/0 CODE - ONLY IF YOU REALLY NEEDED. I will also recommend Adan Bien's excellent book
Real World Java EE Patterns Rethinking Best Practices. In my opinion this is the best EJB3x on the planet :-)
Also you will find a nice DAO in the CRANK framework
(BTW: I have merged Biens CRUD service and some parts of the Kank DAO here: seam-utils-ejb)