DAO's are dead? DAO's vs. NamedQuery

[deanhiller2000]

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.

That has significantly reduced our code base and complexity of the system.  The stateful bean pattern is way easier(without DAOs) as you just use the EntityManager and pass it in to the Data access static method on the bean, so complexity is significantly reduced there.  In fact, I don't even know how to do a statefull bean with an extended persistence context using DAO!!!!  I only can do it without DAO write now(just my lack of knowledge and the fact that it is much more work to figure out something that seems to not have a benefit)

Some may argue slipping in another DAO implementation is now harder.  Well, we have about 30 DAO's on our project so slipping it in now is just as hard.  In fact, I would almost prefer to slip in a different EntityManager instead for testing(which I have done before) and keep the code as is.

On 3 projects and 2 years, I don't see the DAO buying anything except more work these days.  Maybe I am missing something?  I have heard some say you will regret it someday when you need to switch to file system or some system, but when I walk through the switch in both DAO style and non-DAO style, there is just as much coding on both sides to code in that file system(less by my count actually when we did a mock use case)...in fact, I may just implement the EntityManager and code the fileSystem behind that.  Of course, reality is you are probably using EntityManager because it is a database and you need transactional support which a filesystem doesn't provide so the likelyhood of a switch is about 0.0001%....a risk I am willing to take to make our code base simple and the team productive.

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.

thoughts?
thanks,
Dean

[asookazian]

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...

[deanhiller2000]

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.

later,
Dean

[asookazian]

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.

later,
Dean

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).

[luxspes]

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.

Validation is no argument for @Entities: Client side needs to be done in Javascript anyway, and complex app specific serverside validation ends up written in Java (or as triggers in the database), so, what is the real value of annotations?

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 it depends. I also see lots of articles about the benefits of @Entities, but I seem to be doing all-right without them (and note that I coded with ORMs for years, I am no newbie in this stuff, and I still believe there are problems that a good match for them). But for webapplications... if the page is readonly... java.util.Map is good enough... it it is read/write and simple, java.util.Map is still good enough... and if is read/write and really complex (very interactive UI)... then most of the code goes to Javascript, which again makes @Entities and their features irrelevant.

I remember reading somewhere that there was a way to ask Hibernate to use java.util.Map instead of Java Beans... if I could use that, and have the hbm.xml dynamically change on runtime as the database change... and then something like OData Server on top of it so that I could access stuff from Javascript... that would be perfect for my current needs (and I am guessing that for the needs of many others). No more need for DAOs, @Entities, an most of the server side programming we do nowdays.

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?

[leifoo]

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)