Hello,

I have started a Blog on how to keep a Domain Model free of persistence logic (http://ricbrown.blogspot.com/2004/09/transparent-persistence-paradox.html).

I was wondering how Hibernate handles keeping persistence logic out of the Domain Model when the domain logic needs to search a large collection of elements (e.g., to check that a property is unique)?

Regards,
Richard

This is too vague and long to answer this question, Yiou should read the reference guide for such first level apporach.

I'd like to answer that last question in case someone searches for this (important) distinction. This has also been a FAQ recently:

"If domain logic needs to search large collections for unique elements" is the goal. This is actually two steps:

1. Search for a pattern
2. Execute some routine depending on the result

Now, I'd say that 1. is definitely data access, right? This goes into a DAO, for example, it might be executed by calling "findItemByPattern(Pattern p)".

The second part of this is the actual "business" logic. It should be inside your domain model implementation, e.g. the Item class has a "doSomething(Collection<Item> domainObjects)". As you can see, the parameter here is a collection of (possible other) business class instances. There is no need for additional data access inside the implementation of this method, it gets all required data in the call arguments.

Who calls this method? Who calls the DAO method first to get the Collection? This is called "control logic" or "use case flow" and its the job of the C in an MVC application design. That is, you usually have control logic in your servlet or EJB session bean. It might help to think of the 1. and 2. as steps that have to be executed and that several steps make a particular use case.

Summary: Think about data access, control- and business logic when designing your system. Don't mix them (there are exceptions to this rule, of course).

The problem to me here is that it still feels to me like this belongs in the domain model (even though I agree that the domain model shouldn't be directly accessing the persistence layer).

I have a problem at the moment where some of my validation envolves the number of child objects: Lets say I cant delete an Order if it contains Order Items.
So, from your approach above, our service layer would do something like this:



However, to me, (very knew to ORM, so I know that doesn't count for much), this isn't very far away from Anemic Domain model.
Our service layer ends up potentially knowing about every business rule!
Maybe it's ok for one specific case, but the solution seems to degrade pretty quickly as the number of business rules increases.

Unfortunately, I can't think of a much neater solution without the Domain model knowing (explicitly or implicitly) about the persistence layer.

Any thoughts?

Dave

Why is that bad? Someone has to!

Im not saying its bad - just that I'd prefer to keep my business rules / logic encapsulated inside my business objects rather than distributed between them and the service layer.

For my particular use cases, it turns out to not be a problem (as the number of associations will typically be small - its fine for me to just have a lazy loading collection, and hit the database as and when I need to exercise my "count items" use case).