Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
My system is connecting to Oracle through Hibernate/JDBC. I want to restructure it using abstraction to decouple its implementation from Hibernate library. That’s a backup for someday the team can switch to another JPA implementation without painful to change core business logic to adapter with new JPA implementation. What are advices in doing this?
By the way, I want some advice from gurus what are common practices/tactics to decouple existing projects from external open source jars?
Direct dependence on standard and popular open source libraries is OK. You shouldn’t consider it as a problem. For e.g I have a large code base and it depends upon joda-time, google-guava etc. Now, coming to your situation, following is my view point
There is very less chance that you move from one JPA implementation to another because by the time you get familiar with a particular implementation (yes implementation because you might want to optimize something or you are looking for some feature that is missing from standard JPA api) it would take some time and you really doesn’t want to spend the same effort learning other implementation (business doesn’t let you even if you want to ;-)).
Spring already abstracts most of the regularly used API’s like JPA, JMS etc. so I suggest you look at that option.