Exposing Hibernate Criteria in Domain Repository

[debasishg]

I have a domain repository IRestaurantRepository, which is being used for all query purposes on the Restaurant domain entity. Now the implementation of the repository is based on Hibernate and JPA - I am fine with that. But, if I want to give the users a flexibility to compose his own query criteria (which is often the case with rich query screens), I have to expose Hibernate Criteria object to the client in the interface IRestaurantRepository. e.g.

interface IRestaurantRepository {
    // finders
    List<Restaurant> find(final DetachedCriteria cri);
    // other finders
}

I don't like this idea of exposing Hibernate classes in my domain interface. I tried with Hibernate Example class, passing the POJO Restaurant in the contract and cooking up the query with the help of Example (Query By Example) in the implementation. But again, Example is messy when we deal with nested properties being set in the POJO.

Any solutions, best practices ?

Thanks.
- Debasish

[jwray]

Debasish,

I went through the same thought processes a while ago and ended up exposing DetachedCriteria in my service layer and allowing clients (swing and web) to construct their own queries.

Before this (in Hibernate 2 when DetachedCriteria did not exist) I had a home grown query definition language that my dao converted to hibernate criteria. Exposing DetachedCriteria made this part of my code-base (which was pretty complex and hard to extend/maintain) redundant. As you say, the downside is having your service layer depend on Hibernate. An alternative is writing your own generic criteria API to work with JPA.

One alternative I want to look into more is the Lucene integration provided by either Hibernate annotations or compass (http://www.opensymphony.com/compass/) both of which allow generic querying into an indexed version of your domain model.

hope that helps.
Jonny

I have a domain repository IRestaurantRepository, which is being used for all query purposes on the Restaurant domain entity. Now the implementation of the repository is based on Hibernate and JPA - I am fine with that. But, if I want to give the users a flexibility to compose his own query criteria (which is often the case with rich query screens), I have to expose Hibernate Criteria object to the client in the interface IRestaurantRepository. e.g.

interface IRestaurantRepository {
    // finders
    List<Restaurant> find(final DetachedCriteria cri);
    // other finders
}

I don't like this idea of exposing Hibernate classes in my domain interface. I tried with Hibernate Example class, passing the POJO Restaurant in the contract and cooking up the query with the help of Example (Query By Example) in the implementation. But again, Example is messy when we deal with nested properties being set in the POJO.

Any solutions, best practices ?

Thanks.
- Debasish

[debasishg]

I went through the same thought processes a while ago and ended up exposing DetachedCriteria in my service layer and allowing clients (swing and web) to construct their own queries.

Good to hear that I am not thinking something totally south.

Before this (in Hibernate 2 when DetachedCriteria did not exist) I had a home grown query definition language that my dao converted to hibernate criteria. Exposing DetachedCriteria made this part of my code-base (which was pretty complex and hard to extend/maintain) redundant. As you say, the downside is having your service layer depend on Hibernate. An alternative is writing your own generic criteria API to work with JPA.

I was almost tempted to do the same when I thought of posting it here. Thanks for the feedback and the Lucene pointer.

Thanks.
- Debasish