-
1. Re: DAO's are dead? DAO's vs. NamedQuery
asookazian Mar 24, 2010 11:06 PM (in response to deanhiller2000)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...
-
2. Re: DAO's are dead? DAO's vs. NamedQuery
deanhiller2000 Mar 25, 2010 7:27 PM (in response to 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 -
3. Re: DAO's are dead? DAO's vs. NamedQuery
asookazian Mar 25, 2010 7:32 PM (in response to deanhiller2000)
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,
DeanI 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).
-
4. Re: DAO's are dead? DAO's vs. NamedQuery
luxspes Mar 25, 2010 7:41 PM (in response to 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.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?
-
5. Re: DAO's are dead? DAO's vs. NamedQuery
leifoo Mar 26, 2010 8:35 AM (in response to deanhiller2000)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 bookReal 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)