I've seen lot's of people writing (or using) third party abstraction frameworks on top of ORM solutions like Hibernate so that they can potentially get rid of one ORM engine to another (or even an other technology). Such frameworks are even considered by some architectsas a must-have.
Praiseworthy, but raising more issues than fixing ones. When you abstract technologies
like Hibernate to make them portable
, you end up sacrificing
lot's of power and functionalities. Simply because semantics are slightly different from
one engine to an other.
Let's play with statistics:
- in 1% of the applications, the need for a switch from one ORM engine to an other arise
- in 99% of the applications, the need for one or several advanced features of ORM arise
You should focus on using and knowing your ORM engine and not on spending time in writing (or using) an abstraction framework.
When using abstraction frameworks you haven't written, other kind of problems actually show up.
When your ORM engine introduce new APIs or new features, you have to wait for the abstraction framework to release accordingly making you dependent on someone else's agenda.
You no longer know (either by heart or at all) the actual method abstraction (or semantic alteration) introduced on top of your ORM engine. This user learnt it the hard way (and he is unfortunately not alone), Spring's /HibernateTemplate/ wraps the Hibernate methods without even giving you a hint about the actual semantic.
The only proper abstraction between an ORM engine and another is a common specification they adhere to. This is one of the reasons why JPA (EJB 3.0) has been introduced. Why is it the only way? Because a specification describes in a very detailed way the common semantic the various ORM engines have to follow.
So please, think twice before using some random proprietary abstraction framework (open source or not). They usually bring no value add but increasing bug areas... Specifications are here to solve the engine abstraction problem (but once again, this is a concern in very few applications).
PS in case someone is misleading, I'm not arguing against DAO layers
