[OT] Generic search in Hibernate

[Richard Wallace <rw...@thewallacepack.net>]

Hey all,

I'm just wondering how anyone has implemented like a generic search 
using Hibernate as a backend.  More specifically, when the data access 
layer (Hibernate) is abstracted away from the presentation layer (JSF).

I I'm trying to find some way of creating some kind of search ability 
that can have a user defined number and type of parameters.  The problem 
I'm running into is that the data access library being used is 
completely abstracted from JSF so I need some neutral type of criteria 
or query to pass to the underlying system. 

I've toyed with creating a custom criteria API that can then be 
translated into whatever backend criteria API is in use, whether it's 
Hibernate, EJB 3 or something else.  But it's a complicated issue even 
for some of the seemingly simple things that I'm trying to do.


How do you guys approach this kind of problem?

Thanks,
Rich

Re: [OT] Generic search in Hibernate

[Werner Punz <we...@gmx.at>]

Richard Wallace wrote:
> 
> Alright, it sounds like there are a couple of approaches that I can
> explore.
> 1) Passing a list of parameters to the DAOs and let them build the
> criteria or query to be executed.  One interesting thing here is that I
> could actually use some query by example kind of thing and then just use
> Hibernates query by example capabilities.  Otherwise, this is probably
> going to be something like a list of some kind of object that
> encapsulates the property, the operation and the value to do the
> filtering with.  This would limit me to doing only disjunctions and
> conjunctions, but it does put all the data access specific logic in the
> DAOs where they should be.
> 
> 2) Expose a Search component that is specific to the underlying data
> access method being used.  This would be separate from all the other
> service and DAO components.  Then a set of search functionality in JSF
> would just use that Search component to do whatever it needs.  In the
> case of a Hibernate search component it would need to pass
> DetachedCriteria.  This probably isn't the cleanest solution but it is
> probably the most flexible and it does centralize where changes need to
> be made in order to perform searches.  One plus is that this Search
> component would be easy to use across projects.
> 
> I think I'm going to try out the 2nd approach first because it does give
> me the most flexibility and will be the quickest to implement.  What do
> you think?
> 
Well from a pure academic standpoint #2 would be a no go, but heck give
it a try, in the end getting the expected results is what counts
and the customer does not appreciate the extra work you have to do
for a clean isolation of concern in many cases.
I sometimes break the clean BO/DAO structure in some cases to get the results
as fast as possible, the key is not to do it too often you might end up
in a huge mess that way.

I still probably would try approach #1 however if moving from one orm solution to the
other is a huge concern, but you cannot cover every
situation like that in a clean way.

Re: [OT] Generic search in Hibernate

[Richard Wallace <rw...@thewallacepack.net>]

Werner Punz wrote:
> Richard Wallace wrote:
>   
>> How do you normally do search functionality like this?  Do you expose
>> the Hibernate query API to the JSF layer?
>>     
> No, that is why the BO-DAO Pattern existis, I usually
> and that works exceptionally well, split the application
> into three layers
> one which is tied to JSF sort of the UI layer then the business object
> layer which encapsules all the functionality needed in a semi/reusable
> abstracted business layer and over that layer automated transactions
> are woven via aop (spring in the last two cases)
> and the pure database access is moved into DAO objects.
>
> It is more overhead to program, but in the end you get resuable business logic
> and a rather good abstraction of the data access layer.
>
> In the long run probably a move of the BO layer to EJB3 will make sense
> (I am using Spring for that now)
> but EJB was sort of a no touch thing to me, up until recently, due to the overhead
> complexity and glue code involved with it, that will change soon with EJB3.
>
>   
Yes, this is the EXACT situation I'm in.  I have my DAOs only doing data 
access and have a BO, or "service" layer, that is where I do all the 
more complicated business logic stuff and JSF only ever accesses the 
service API.  I also use Spring and have my transactions woven in with 
aop and plan to also use acegi to weave in authorization.
>   
>> The main reason I wanted to try and abstract it was in case we did see
>> some need in the future to swtich to a different ORM tool like EJB 3 or
>> whatever else is the latest greatest.  I mean, in theory, the
>> presentation layer shouldn't care one wit what the data access layer
>> uses to get it's job done.  That's the whole reason for abstracting the
>> Hibernate stuff in DAOs.
>>     
> I think DAO should be enough, you just pass the parameter lists
> you determine into the DAO and have the query logic there
> figure it out.
> No need for another layer of query abstraction,
> you might also consider to move all your query stuff which is not
> categorized to a central place so that you can adjust that.
> But moving that stuff into a DAO layer if you do it cleanly should
> be sufficient to give you the chance to move the
> data access into another system, one of the reasons why
> the DAO pattern exists at all.
>
>   
The only reason I'm reluctant to do something like a parameter list is 
because it's pretty limited to the kind of queries you can do.  Usually 
you'll be stuck only doing an and or an or on all the parameters and 
can't really do anything more complex.  For most situations that would 
be ok but there are a couple of situations in which I will need to be 
able to do more expressive queries.
>   
>> I don't think my situation is all that different from others that are
>> out there.  I have Hibernate at the lowest level doing data access,
>> spring in the middle managing services which use the data access layer
>> and then JSF at the presentation layer utilizing the APIs the services
>> expose.  I guess I'm just curious about what the best practices are and
>> what people would think if I exposed the fact that the data layer is
>> using Hibernate at the presentation layer by using the Hibernate
>> criteria API.
>>
>>     
> No as I said... push the query data through your layers
> as POJOs into the DAO layer and have the dao layer deal with it on the query level.
> But do not push controls or something else JSF related into either the Business Layer
> or the DAO layer, you lose portability and and up in a mess which is hard to clean
> afterwards.
>
> Generally following the DAO-BO approach with a clean separation of concerns
> is currently to my knowledge considered a very good approach. You get other benefits
> from it, like you can AOP the interfaces and do other stuff (like adding automated transaction
> handling on business level, you can do a simulation on parts of the system
> which are not finished and then IoC the parts you just get in etc...)
>
> The downside of this pattern is, it is rather
> coding intensive and definitely not suitable for
> quick hacks and swiftly written applications.
> The ideal idea would be to have a collection of
> business objects which you can apply to a workflow
> the system has to perform, but that idea is unfortunately good on paper
> but does not work out as expected in reality. Hence the whole EJB approach
> sort of was a good idea but did not work fully out.
>
>   
Alright, it sounds like there are a couple of approaches that I can 
explore. 

1) Passing a list of parameters to the DAOs and let them build the 
criteria or query to be executed.  One interesting thing here is that I 
could actually use some query by example kind of thing and then just use 
Hibernates query by example capabilities.  Otherwise, this is probably 
going to be something like a list of some kind of object that 
encapsulates the property, the operation and the value to do the 
filtering with.  This would limit me to doing only disjunctions and 
conjunctions, but it does put all the data access specific logic in the 
DAOs where they should be.

2) Expose a Search component that is specific to the underlying data 
access method being used.  This would be separate from all the other 
service and DAO components.  Then a set of search functionality in JSF 
would just use that Search component to do whatever it needs.  In the 
case of a Hibernate search component it would need to pass 
DetachedCriteria.  This probably isn't the cleanest solution but it is 
probably the most flexible and it does centralize where changes need to 
be made in order to perform searches.  One plus is that this Search 
component would be easy to use across projects.

I think I'm going to try out the 2nd approach first because it does give 
me the most flexibility and will be the quickest to implement.  What do 
you think?

Thanks for all the input Werner, I really appreciate it,
Rich

Re: [OT] Generic search in Hibernate

[Werner Punz <we...@gmx.at>]

Richard Wallace wrote:
> How do you normally do search functionality like this?  Do you expose
> the Hibernate query API to the JSF layer?
No, that is why the BO-DAO Pattern existis, I usually
and that works exceptionally well, split the application
into three layers
one which is tied to JSF sort of the UI layer then the business object
layer which encapsules all the functionality needed in a semi/reusable
abstracted business layer and over that layer automated transactions
are woven via aop (spring in the last two cases)
and the pure database access is moved into DAO objects.

It is more overhead to program, but in the end you get resuable business logic
and a rather good abstraction of the data access layer.

In the long run probably a move of the BO layer to EJB3 will make sense
(I am using Spring for that now)
but EJB was sort of a no touch thing to me, up until recently, due to the overhead
complexity and glue code involved with it, that will change soon with EJB3.


> The main reason I wanted to try and abstract it was in case we did see
> some need in the future to swtich to a different ORM tool like EJB 3 or
> whatever else is the latest greatest.  I mean, in theory, the
> presentation layer shouldn't care one wit what the data access layer
> uses to get it's job done.  That's the whole reason for abstracting the
> Hibernate stuff in DAOs.
I think DAO should be enough, you just pass the parameter lists
you determine into the DAO and have the query logic there
figure it out.
No need for another layer of query abstraction,
you might also consider to move all your query stuff which is not
categorized to a central place so that you can adjust that.
But moving that stuff into a DAO layer if you do it cleanly should
be sufficient to give you the chance to move the
data access into another system, one of the reasons why
the DAO pattern exists at all.


> I don't think my situation is all that different from others that are
> out there.  I have Hibernate at the lowest level doing data access,
> spring in the middle managing services which use the data access layer
> and then JSF at the presentation layer utilizing the APIs the services
> expose.  I guess I'm just curious about what the best practices are and
> what people would think if I exposed the fact that the data layer is
> using Hibernate at the presentation layer by using the Hibernate
> criteria API.
> 
No as I said... push the query data through your layers
as POJOs into the DAO layer and have the dao layer deal with it on the query level.
But do not push controls or something else JSF related into either the Business Layer
or the DAO layer, you lose portability and and up in a mess which is hard to clean
afterwards.

Generally following the DAO-BO approach with a clean separation of concerns
is currently to my knowledge considered a very good approach. You get other benefits
from it, like you can AOP the interfaces and do other stuff (like adding automated transaction
handling on business level, you can do a simulation on parts of the system
which are not finished and then IoC the parts you just get in etc...)

The downside of this pattern is, it is rather
coding intensive and definitely not suitable for
quick hacks and swiftly written applications.
The ideal idea would be to have a collection of
business objects which you can apply to a workflow
the system has to perform, but that idea is unfortunately good on paper
but does not work out as expected in reality. Hence the whole EJB approach
sort of was a good idea but did not work fully out.

Re: [OT] Generic search in Hibernate

[Julián García <jg...@unionsoluciones.com.co>]

I use a very similar arquitechture. I use Hibernate Criteria  hidden in 
DAOs' implementations. I code my services to DAO interfaces. Changing my 
  data access layer is just coding different implementations to the same 
interfaces.


Richard Wallace wrote:
> How do you normally do search functionality like this?  Do you expose 
> the Hibernate query API to the JSF layer?
> The main reason I wanted to try and abstract it was in case we did see 
> some need in the future to swtich to a different ORM tool like EJB 3 or 
> whatever else is the latest greatest.  I mean, in theory, the 
> presentation layer shouldn't care one wit what the data access layer 
> uses to get it's job done.  That's the whole reason for abstracting the 
> Hibernate stuff in DAOs.
> I don't think my situation is all that different from others that are 
> out there.  I have Hibernate at the lowest level doing data access, 
> spring in the middle managing services which use the data access layer 
> and then JSF at the presentation layer utilizing the APIs the services 
> expose.  I guess I'm just curious about what the best practices are and 
> what people would think if I exposed the fact that the data layer is 
> using Hibernate at the presentation layer by using the Hibernate 
> criteria API.
> 
> Werner Punz wrote:
> 
>> Richard Wallace wrote:
>>  
>>
>>> Hey all,
>>>
>>> I'm just wondering how anyone has implemented like a generic search
>>> using Hibernate as a backend.  More specifically, when the data access
>>> layer (Hibernate) is abstracted away from the presentation layer (JSF).
>>>
>>> I I'm trying to find some way of creating some kind of search ability
>>> that can have a user defined number and type of parameters.  The problem
>>> I'm running into is that the data access library being used is
>>> completely abstracted from JSF so I need some neutral type of criteria
>>> or query to pass to the underlying system.
>>> I've toyed with creating a custom criteria API that can then be
>>> translated into whatever backend criteria API is in use, whether it's
>>> Hibernate, EJB 3 or something else.  But it's a complicated issue even
>>> for some of the seemingly simple things that I'm trying to do.
>>>
>>>
>>>     
>>
>> Well abstracting the already abstracted hibernate query api does not 
>> really
>> make that much sense unless you plan to switch the db access layers.
>> All I can say is, dont do it and even if you try to do it, it is not 
>> worth
>> the effort.
>>
>> But as for crtieria queries, you can go for the Hibernate criteria 
>> queries
>> to get a dynamic query behavior.
>>
>>   
> 
> 

Re: [OT] Generic search in Hibernate

[Richard Wallace <rw...@thewallacepack.net>]

How do you normally do search functionality like this?  Do you expose 
the Hibernate query API to the JSF layer? 

The main reason I wanted to try and abstract it was in case we did see 
some need in the future to swtich to a different ORM tool like EJB 3 or 
whatever else is the latest greatest.  I mean, in theory, the 
presentation layer shouldn't care one wit what the data access layer 
uses to get it's job done.  That's the whole reason for abstracting the 
Hibernate stuff in DAOs. 

I don't think my situation is all that different from others that are 
out there.  I have Hibernate at the lowest level doing data access, 
spring in the middle managing services which use the data access layer 
and then JSF at the presentation layer utilizing the APIs the services 
expose.  I guess I'm just curious about what the best practices are and 
what people would think if I exposed the fact that the data layer is 
using Hibernate at the presentation layer by using the Hibernate 
criteria API.

Werner Punz wrote:
> Richard Wallace wrote:
>   
>> Hey all,
>>
>> I'm just wondering how anyone has implemented like a generic search
>> using Hibernate as a backend.  More specifically, when the data access
>> layer (Hibernate) is abstracted away from the presentation layer (JSF).
>>
>> I I'm trying to find some way of creating some kind of search ability
>> that can have a user defined number and type of parameters.  The problem
>> I'm running into is that the data access library being used is
>> completely abstracted from JSF so I need some neutral type of criteria
>> or query to pass to the underlying system.
>> I've toyed with creating a custom criteria API that can then be
>> translated into whatever backend criteria API is in use, whether it's
>> Hibernate, EJB 3 or something else.  But it's a complicated issue even
>> for some of the seemingly simple things that I'm trying to do.
>>
>>
>>     
> Well abstracting the already abstracted hibernate query api does not really
> make that much sense unless you plan to switch the db access layers.
> All I can say is, dont do it and even if you try to do it, it is not worth
> the effort.
>
> But as for crtieria queries, you can go for the Hibernate criteria queries
> to get a dynamic query behavior.
>
>   

Re: [OT] Generic search in Hibernate

[Werner Punz <we...@gmx.at>]

Richard Wallace wrote:
> Hey all,
> 
> I'm just wondering how anyone has implemented like a generic search
> using Hibernate as a backend.  More specifically, when the data access
> layer (Hibernate) is abstracted away from the presentation layer (JSF).
> 
> I I'm trying to find some way of creating some kind of search ability
> that can have a user defined number and type of parameters.  The problem
> I'm running into is that the data access library being used is
> completely abstracted from JSF so I need some neutral type of criteria
> or query to pass to the underlying system.
> I've toyed with creating a custom criteria API that can then be
> translated into whatever backend criteria API is in use, whether it's
> Hibernate, EJB 3 or something else.  But it's a complicated issue even
> for some of the seemingly simple things that I'm trying to do.
> 
> 
Well abstracting the already abstracted hibernate query api does not really
make that much sense unless you plan to switch the db access layers.
All I can say is, dont do it and even if you try to do it, it is not worth
the effort.

But as for crtieria queries, you can go for the Hibernate criteria queries
to get a dynamic query behavior.