These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]

Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
 Post subject: Interesting ORM design condideration
PostPosted: Sun Feb 06, 2005 2:12 am 

Joined: Fri Feb 04, 2005 11:39 pm
Posts: 13
I am a recent "convert" from ejb2.x to Hibernate. I am all excited about how a true ORM tool like Hibernate can enable a "domain driven design" which basically encapsulates all domain data and behaviour within the domain objects (almost all of which are persistent object).

I just finished the book "Hibernate in Action" and tried to imbibe all design and implementation concepts taught in the book.

Now, there is a real "conflict of interest" between completely encapsulating business logic in Domain objects and avoiding dependence of domain objects on the underlying persistence framework so that they can be freely passed around among different layers.

In order to achieve this, we need the service layer to retrieve all persistent data required to execute all business rules using DAOs and pass it as arguments to the domain business objects.

This leads to partial leakage of business rule execution concern out of domain objects to the service layer.

For exapmple, I have a use case to modify an Operation for which I define a method Operation.modify(...). This method needs to check whether there is any other "duplicate operation" in the database. So, I need to pass number of "duplicate operations" to this business method. The service layer needs to call DAO to get the number of duplicate operations. Now, retrieving "duplicate operations" based on certain search criteria itself is a business rule, which leaks out of the domain model.

From this point of view, it would be better to evan retrieve the number of duplicate events within the business method, but this will make POJO dependent on DAO and hence the underlying persistence framwork.

So we have two design scnarios:

1. service layer->dao

pros: POJOS have no direct/indiect dependency on persistence framework.

cons: partial leakage of domain business rule execution to service layer

2. service layer -> pojo -> dao

pros: Domain logic completely encapsulated in domain objects.
cons: Although decoupled, pojos have run time dependency on the persistence framework.

Considering the tradeoff, I think scenario one is better if we want to pass around our pojos across different layers/tiers and scenario two is better if we have to use dtos (may be because our view object hierarchy does not at all match our domain object hierarchy) to pass data to the presentation layer, because in that case we need to deploy pojos only to the business layer/tier.

 Post subject:
PostPosted: Mon Feb 07, 2005 4:46 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
1 is definetly OK, you should only have invariant rules in your domain model IMO.


Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

All times are UTC - 5 hours [ DST ]

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.