I feel bad design when I forced to create no-argument constructor and getters/setters for my persistent classes by Hibernate. Anybody here who have ideas on how to avoid it?

The way I'm thinking on how to approach it is to use Memento pattern
http://home.earthlink.net/~huston2/dp/memento.html
Somebody who used it with Hibernate?

Many thanks.

many options

constructor does not need to be public

access="field"

interceptor.instantiate()

Thanks Max. The point I'm moving from is
http://www.hibernate.org/hib_docs/v3/re ... onstructor

Package visibility is also unlikely option. Not sure what proxy generation is for but I would follow Hibernate documentation recommendations.

proxying is for providing lazy loading, and if you constructor is less than package visible we cant invoke it to create the object.

This is why I'm researching the possibility to apply Memento here. The model I'm thinking about is something like:
- Memento holds state of Entity object. Memento is written according to Hibernate rules (default constructor, getters and setters).
- Entity class have constructor with Memento parameter and is able to instantiate itself from Memento.
- DAO loads Memento from database using Hibernate, and then instantiates Entity using Memento.

Is it possible with Hibernate?

so for each DomainObject you would have a DomainObjectMemento - basically duplicating your whole class hiearchy ?

sounds more like a anti pattern to me ,)

besides - this will work with hibernate, but you would loose alot of great functionality since one thing is loading...another is saving.

You are actually mimicing what is so bad about DTO's ..

Thanks Max. Memento vs no-args constructor is the subject for another discussion. What I am sure about is that I want to research all the possibilities with both sides.

What Hibernate functionality I'm losing doing this way? I'm especially concerned about business logic or application transactions.

well basically you would need to copy all data from your entity back to the memento to let hibernate save it.

And that is non-trivial for object graphs etc.

This is how Memento is working


Yes - another concern. I'm thinking about - in my entity graph do not hold references to actual persistent Entities but to entity IDs.

okey - so you think package protected default constructors are bad design, but still want to expose ids in your entities.

Well well ,)

I used a object model that only had ids as ref purely because I had to run on a system where the id could be different things at certain points and that I could not define in e.g. a ORM tool how to get it.....

why are you having ID's and not just refs to it ?

-max

Hey Max


We might be talking about the same thing actually. I see my Entity will hold reference to another Entity objects (which are identified by IDs they contain). While storing / retrieving from db, Memento could contain IDs of instances my Entity is referring to.

and as such you are redoing what Session does....keeping track of which id that corresponds to a certain entity and if and entity is not yet loaded then get it....

you will be doing a lot of redundant internal bookkeeping...