From the simplicity of my question I have no doubt that this question has been answered before, but I have not been able to find the answer searching these forums, and a reason of "why not" is not given in the documentation.

If you have a POJO "Cat", why is it that we have to have a CatDAO class to manage persistence? I know we dont "have to", but is it not possible to create a base class that has "save", "delete", "getById" and some kind of "getList(filter)" functionality? It seems so redundant to have to definte these for each object type I create.

I have not seen this anywhere and I wonder why. Im guessing its one of these two reasons.

There is no clean way of doing this. I notice you have to pass in the class name to session.save, but im sure there are work arounds?

For some reason this is a bad design decision when using hibernate.

Thank you in advance for the help, and believe me when I say I searched through the documentation, the forums and caveatemptor sample project.

I do know that people might want to keep a POJO a pojo, but to me it seems that I might be willing to have this trade-off although I understand coupling is a no-no.

I often use the same pojo used in the data access layer in the web layer...where it doesn't have access to a session. In the web layer save, update, and gets won't work. Defining save, update, and gets in the pojos makes the web layer code confusing.

Besides in most cases, we don't expose individual pojo operations to the web layer. We use functions that do several things. Save order would save each of the items in the order and fire off the fulfillment messages in the same transaction.

In a way, we use hibernate session as our DAO. So, dao per pojo is not neccesary.

Transparent persistence is what seperates hibernate (and a few tiny competitors) from EJBs (which are closer to what you are describing). With a POJO, your business code is more portable, more testable, and still useful outside of whatever framework/container that actually implements the persistence.

I see... basically the whole point(or a part of it) is the abstraction.

See Gavin's interview on serverside.com for more on that.

I'll take a look at that video as soon as I get home(no speakers on work comp), should be interesting.

Quick question for you, I have a db that has about 30 tables, is it normal to define 30 different DA classes, or don't wrap that logic at all?

e.g there seems to be 3 ways I can do this:

1. write all the seperate data access classes so I can do stuff like.

Cat cat = new Cat();
CatDA.save(cat);

pros: clean code
cons: define a class for each business object, ouch!

2. write the code there

Cat cat = new Cat();

//open hibernate session etc.

session.saveOrUpdate(cat);

pros: no special data access class
cons: ugly?! no code re-use

3. Some other mechanism. It seems I would want to define a single class that could handle any object type, but not sure how this would like. This might not cover special conditions like when transactions need to be handled, but I would like to use it 90% of the time.

I believe #2 is the more popular pattern these days.