I am working on a designing a core framework/common components that abstract the details of the underlying persistence mechanism from the client code. For example, the client code would configure a datasource and then request from framework for connections (may hand back a Hibernate Session, may hand back a JDBC connection etc...). I am curious if there are any risks or considerations when wrapping or abstracting Hibernate in this manner. By reviewing the Spring source code (hibernate-specific packages) it is clear they are doing some level of session management (i.e. check for open sessions and re-use them if possible); should I be worried about the same? I was planning on handing the Session to the user and keeping everything from the SessionFactory, it's creation and configuration shielded from the client code.

Why do something like this? We have many off-shore teams that build our applications and we need to ensure a standard way of using our core technologies. Wrapping these technologies gives us the control we need on the application side as well as provides us the ability to move to new technologies with minimal impact to the client code.

Any help or direction on this matter is deeply appreciated.
-derrick

Well, it just sounds like you're really implementing a DAO access pattern, where data access and its implementation is abstracted out from the client. It's a good idea, or should I say, a great idea, and that's why the Data Access Pattern is a pattern, and not an anti-pattern.

Check out my tutorial on implementing the DAO pattern with Hibernate and Generics. It might help point you in the right direction.

http://jpa.ezhibernate.com/Javacode/learn.jsp?tutorial=21advanceddaos

Now, one thing I would say is that Hibernate itself abstracts out much of the database access layer. In fact, some say that Hibernate and EJB3.0 does such a good job of it, that it eliminates the need for the DAO pattern altogether. I don't agree, but it does create an interesting talking point in various Java forums.

One problem I have seen though is over-engineering a good framework. I've seen people build frameworks around Hibernate. People that think they know Hibernate better than the people that invented it, and they do all sorts of wrapping around it. In the end, they end up crippling the framework, as they remove key functionality, and hit problems that they never anticipated. It's a huge pitfall.

Man people like Hibernate because it strikes a balance between a good framework, while at the same time giving the developer some control. Framework bloat has been a real problem in the Java community. I think Hibernate strikes a great balance between control and abstraction. Make sure that whatever abstract implementation you create doesn't cripple the ability of your clients to be creative and exert ingenuity!

Cameron, thanks for the reply. I did look at the DAO pattern as a possible solution and did have some mock code written that implements the pattern. I will have to revisit this code as there was some coupling between the persistence technology and what would be the client code.