So we are getting rolling with Hibernate in earnest and digging it.

We are defining our data model with mapping files and generating everythign else (Java classes and SQL) from the mappings. This is working nicely since it allows us to experiment with mappings (for educational purposes) and see the results both in the Java and in the SQL.

The problem, though, is that the generated Java classes are plain old beans.

Now we are getting to the point where we want to add domain model logic to the domain objects.

The question is, how can we add domain logic (more methods, invariants in setters, etc., etc.) to the domain objects, and still maintain the very nice property that the domain objects are auto-generated by Hibernate?

Perhaps the answer is "You can't. Duh." But maybe there is a best practice here that we're just not aware of....?

Right now we are defining separate DAO classes (which tend to be mostly static methods! too procedural! we're missing something here!) that perform operations on the domain objects. In other words, we are implementing operations (finder operations, multi-object updates, etc.) in separate helper classes which are in a layer above the domain model. This is good on the one hand because it keeps Hibernate-specific code out of the domain model (i.e. the Hibernate-generated POJOs), but on the other hand it's bad because we want some of this logic to be in the domain model.

Ah me, can you tell it's our first time designing a tiered enterprise system?!

All feedback (and/or pointers to other threads / discussions) hugely appreciated.

Thanks very much in advance for your generously donated and totally uncompensated time.
Sincerely,
Rob Jellinghaus
robj at nimblefish dot com

Well, I asked a similar question in "Persistent Objects and DAOs" thread http://forum.hibernate.org/viewtopic.php?t=926855, however the answers there didn't help me much with the problem of the Anemic Domain Model (Fowler), which is in fact just a thin data layer over the db and not much more. If you want to put more logic in it, you inevitably end up needing to call the DAOs, which seems not be recommended.

Best regards,
Deyan Petrov

Look at the <meta> tag documentation - here you can see how to make generate abstract classes that you extend and add custom code to....this allows you to re-generate the POJO stuff and keep the logic.

Dont know if that is what you want ?

I'm honestly not sure how to use the <meta> superclass support. I mean, what if I have something like an Order entity which has a bunch of LineItems (you know, the usual example) and I want to write a totalPrice method? This wouldn't work:

// class written by me with domain logic method
abstract class OrderSuperclass {
public float getTotalPrice () {
Enumeration lineItems = this.getLineItems();
// ... add up all the lineItem.getPrice()s...
return totalPrice;
}
}

// class generated by hbm2java with <meta superclass="OrderSuperclass"/>
public class Order extends OrderSuperclass {
public List getLineItems() { return lineItems; }
//...
}


OrderSuperclass won't even compile then! Do I need to add "public abstract List getLineItems()" into OrderSuperclass? If so, doesn't that mean I need to push a lot of the generated methods into the superclass abstractly?

As for your question, Deyan: I am starting to think it's not a big deal to have the domain logic methods just reference the DAOs. This way, you are still hiding all your Hibernate-specific logic (HQL queries, object saving/updating, etc.) in the DAOs, but your domain objects can use your DAOs to do the business CRUD operations they need to do.

Speaking of Fowler, http://www.martinfowler.com/articles/dblogic.html is a pretty good article explaining a concrete interaction between a domain model and a DAO layer. His second example there shows the domain model pattern. In his case, he writes his domain model to assume that all the data its business methods need has already been loaded by the DAO layer. In other words, the domain model never needs to worry about loading data because all the data it cares about has been loaded already (presumably by the service layer).

I am not sure that this pattern scales well, but it is interesting to see how far it can be pushed. If we wind up frustrated with trying to choreograph the loading from the service layer, I will probably try just having domain objects use DAO objects to do the loading they need to do on demand. We'll see how it works out :-)

Cheers!
Rob

Oh, and I forgot one other question: isn't it true that using hbm2java's "creat finder methods" support breaks the "no Hibernate logic in the domain model" guideline espoused by Gavin himself?

Just asking ;-)
Cheers!
Rob

Look for <meta attribute="generated-class"> ....that is what you want.

And the finder stuff is seperated from the domain class...so it won't break the pattern.

It'd be cool if the reference manual mentioned where the finder stuff gets generated *to* -- or even provided a meta attribute to specify what finder class name you want. (Kind of like the generated-class attribute itself.) As it is, the documentation doesn't give any indication of where the finders come out.

But I'll give it a try :-) I assume finders only find by one property, never by multiple? (If you don't answer I'll assume the answer is "yes", so that might save you some time!)

Cheers!
Rob

The finder renderer is just a renderer which is configured by the hbm2java config.xml file...that is documented in section 19.2.1 where you can use the prefix, suffix and package to control the name of the outputting finders.

We have received a patch to handle multiple property finders (As i remember it...search for Finder in JIRA) but it did not work well on the current cvs. (i look forward for any patches ;)