Hi guys,

This question is bothering me since my birth - should the domain model/objects use hibernate objects(session etc) or they should contain logic with no direct reference to the persistence mechanisms and be passed to another (service layer) object that persists them using Hibernate?

I am talking about an architecture consisting of UI, domain model + Hibernate as persistence mechanism, as well as a (thin) service layer.

Have in mind the AccountTransfer example in the following Hibernate thread:

http://sourceforge.net/forum/forum.php? ... _id=128638

I guess that unless there is a thick service layer the domain objects ***should*** have a reference to Hibernate ....

10x in advance for your input,
Deyan Petrov

I never have any dependency from my domain model to Hibernate classes.

Hi,

How do you manage that? You don't call session.xxxx() from a domain object method? You put all business logic in the service layer classes?

Sorry, I was not able to understand you answer. Would you please elaborate how you can have a domain model with something more than just objects and their relationships to other objects(i.e. some business logic creating/deleting other domain objects) and at the same time not use session.xxx() from within a domain objects' methods?

10x in advance,
Deyan Petrov

I am refering in particular to this post that I found:

http://sourceforge.net/forum/message.php?msg_id=2105460

Deyan

Domain object itself has some business logic - like seting
parent references , calculation values etc.

Service layer is responsible to savind / updating domain objects inside hibernate session.

I agree with Gavin. And Ill try to explain from my experience:

Your domain model is meant to be persistent agnostic. This way its easier to reuse it in diffrent scenarios or even using other persistence mechanisms. For example, you could use your domain model in another environment (say an applet or a web service). Leave all the persistence to DAO's (Data Access Objects). DAO's know about your domain objects and are the ones that should encapsulate all persistence details (you oculd use hibernate, or JDO or plain JDBC, or a combination of these).

So basically what your looking at is something like this:

MyObject <- MyObjectDAO -> DB

DAO's in turn, would be used in an upper aplication layer (like the service layer you mentioned), to provide persistence for your domain objects.

I've worked with OR tools for a few years now, and seen the bane of ejb too.
We have a handful of medium sized apps here, where the model is

struts action - service layer - domain model objects - db

Our domain model objects that are mapped DO have business logic.
They do not have persistance code, or refs to hibernate.

Serice layer method looks like so

session.load (MyObject)
Transaction tx = session.beginTrans...

setPropertiesFromTransferObject to domain object
if necessary call bus logic on methods on the domain object

tx.commit

The only real prooblems with this method is
1. If you have to toss an object back to the UI tier, making sure it has initialized any collections the ui may need and
2. making hibernate aware of all the relationships involved, so it can "see" any changes between transaction start, and end

However, it seems very worth the effort, to be able to have real object oriented code, that doesn't look functional at all.

James

Except for Lifecycle, perhaps?

-dc

I don't use Lifecycle. I think it was a mistake. Its one of the very few things I just ripped unthinkingly from other ORM solutions back in the dim dark days.....

I think thats how it should be but sometimes it is not possible because hibernate does not 100% transparent persistence. It's rather 98%.
Let's be a bit more concrete:
We have a class Product with the attributes name and price. Everytime we increase the price for more than 20% we want to create some note for someone else.
The naive version would be:

This will not work with hibernate because hibernate always uses the setMethod while loading the object from DB. Now there are two options:
1. Create some method like setPriceFromHibernate(double price) and allow hibernate to use this.
2. Modify setPrice the following way:

In (1) we create some implicit dependency because if we would use the Product class without hibernate (e.g. in memory) we would not need the special setMethod. A bit ugly but it works.
In (2) we create a hard dependency because we are referencing net.sf.hibernate.
I do not like any of these options and the only way to really solve the problem would be a feature of hibernate that sets the state of an object instance directly (e.g. this.attribute = newvalue) without using setMethods.

My 0.02 EUR
ciao
Sven

If I need to "find" objects, i.e. load objects from the db, in the UI, do I always go through the Service layer, which delegates to the DAO objects, or I call the DAO objects directly?

Best regards,
Deyan Petrov

My question in fact is should all persistent activities related to domain objects pass through the service layer or not? Obviously the Service layer will delegate/use the DAO objects, but should the clients of the application (web UI, web service etc) call retrieve methods on the Service Layer classes only?

10x in advance,
Deyan

access=field in Hibernate 2.1

Uhm... I'm struggling with this one myself. Because we only program for web browsers, we just make the controller (Struts Actions) call DAO's and pass domain objects to the view.

My hunch would be that if you use a service layer it would mainly delegate calling DAO's and such to obtain info from the DB (as domain objects) and pass it to the view (JSP's).

In theory service layers have the potential to make your app easily portable to other presentation technologies (PDA's, etc...) or things like webservices and have application containers help you with stuff like declarative security, logging, etc...).

Any ideas or experiences would be appreciated.

Personally I've settled on an architecture like this:

user interface (struts or swing actions) access service layer
service layer access dao's
dao's access the database (via hibernate).

My domain objects (the mapped, persistant ones) are passed around between layers.

The advantages I find:

i) Conceptually very clean. Sits well in my brain. Easy to explain to others.

ii) Clean delegation of responsibility: the DAO's know how to find, delete etc. your domain objects, and are application independent (and so can be
reused across applications).

The service layer contains the application specific, higher level logic. All transactions occur at this level (in my system at least). I use Spring to manage this declaratively - at this level you can call multiple DAO methods within one transaction easily. At this level you will get some simple service methods that straight delegate to the DAO, but for more complex application logic that calls multiple DAO methods, from multiple DAO's, this obviously is not the case.

iii) The GUI actions just call the needed services and know nothing about DAO's or how to persist or even if data is coming from a database. (Eg, I have one app that gets data from a local database and from a web service. To the application this differential data source is not apparent.)

iv) Very easy to reuse service logic with different GUI interfaces.

v) If distributed app needed, easy to change to a session ejb front end to the service layer.

I'd recommend looking into using Spring to construct and manage your service layer. It really leads to a very clean solution, reducing a lot of plumbing code (for transactions), and really clarified the overall architecure in my head when learning it.

Jonny