using DAO design pattern with Seam apps

[asookazian]

anybody know what the advantages/disadvantages are of using Data access objects with Seam? Apparently Seam supports this (it's in the Yuan book). Not sure if any of the examples in the Seam download used it or not. thx.

[thejavafreak]

The advantage is that you can use the same DAO object by other service.

[asookazian]

The Rod Johnson book entitled "J2EE development without EJB" suggests NOT using DAO pattern when the business tier components are doing mostly persistence code. In that case, it's not worth abstracting the data access tier.

In Pro Spring book, the writer(s) do not recommend a 1-to-1 ratio of DAO to tables in RDBMS.

How would you implement caching using DAO pattern w/ SEAM?

In SEAM apps, it seams to me the SFSB's are doing mostly persistence api work. So perhaps that's why the examples in the SEAM distribution do not use DAO?

[christian.bauer]

Don't quote Rod Johnson bullshit here. In the same book he goes on and basically tells you to not use an ORM software. Don't believe anything he says about data management because he obviously doesn't know what he is talking about.

The fact is that instead of asking "Should I have DAOs" you should ask "what are good reasons for using DAOs". Once you have that list in front of you, you can make an informed decision.

I have listed common reasons for having (and not having) DAOs in my book. Because it is not a simple list but a whole section, I can't quote it here. Go get the ebook.

And yes, I use a DAO-like pattern in my Seam application.

[asookazian]

I actually was reading your (and Gavin's) book last nite as well (JPA and Hibernate) and did see some info on DAO as well as factory pattern.

That book is well written and useful by the way. thx for the feedback.

I'm not sure how much of the "EJB bashing" that Rod does in that book applies to EJB 3.0 (much less probly).

I'm just really hoping that a SEAM heuristics/best practices book comes out soon... This is our main frustration area...

[asookazian]

Don't quote Rod Johnson bullshit here. In the same book he goes on and basically tells you to not use an ORM software. Don't believe anything he says about data management because he obviously doesn't know what he is talking about.

First off I'm not a big advocate of Spring. I think pulling a lot of code into XML is a disaster in most cases. And I think Seam is a big improvement over Struts + EJB 2.x technology from a developer's perspective at least. But Spring integrates out of the box with Hibernate (versions 2 and 3), JDO (versions 1 and 2), TopLink. If Johnson was anti-ORM, why would this be the case then?

To be faire here, his basic premise is in some cases it's advantageous to use ORM and some cases not (use JDBC or iBATIS as myspace.com does for added flexibility). I'm not saying he's right or wrong, just wanted to let his stance be known all here...

[monkeyden]

I'm not sure MySpace can be used as the model for anything but a poorly designed and implemented application. I see CFM and ASP pages on that site and it bombs frequently. Looks like some college kids cranked that out between classes. What does this have to do with Seam, or even enterprise applications?

[christian.bauer]

But Spring integrates out of the box with Hibernate (versions 2 and 3), JDO (versions 1 and 2), TopLink. If Johnson was anti-ORM, why would this be the case then?

There are several years between these events (not liking ORM, selling early Spring to early Hibernate users, adding more wrappers for other tools, and so on). I have no doubt that Rod Johnson now understands ORM better than in his first book and that he realized at some point that the fast adoption of Spring can be attributed to its function as a Hibernate wrapper.