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.
