Jochen Bedersdorfer says:
"I designed a little sub-project using the DAO design pattern to make it independent from the persistence technology. WHAT A WASTE OF TIME! You are writing class after class just plumbing things together, after that your business code looks like a one big mess.
That's completely not my opinion. A DAO layer adds much clarity to the picture and is really easy to implement.
What are the alternatives? An object which executes sql statements on each set and get?
You already posted the link: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html. Have a look at the first picture. Isn't it easy? Without DAO you would need to access the DataSource directly in the BusinessObject. That's how ESQL works - and even this does abstract from the db by generating db-specific code.
I started with DAO as I did not know what persistence framework to use. I heard of limitations of the one and the other. So there was indeed a need for an abstraction of the datasource/persistence framework.
All this nonsense about putting your logic in statless session beans, opening up your persistent beans with numerous public setters/getters is breaking all rules about a clean, encapsulated and simply OO design!
And when reading the above I also got the feeling that he mixes DAO and DTO.
In my current project I also have some business logic specific to a persistent object in them. But nothing prevents you from using this approach with a DAO layer.
While CMPs are DTOs and indeed force you to open much, but there are other patterns that fix this again. Each pattern has advantages and disadvantages. And they are addressed to some use cases, there is no silver bullet.
The DAO pattern is a first good and easy step away from XSP/ESQL IMO.
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
