Is staying implementation agnostic really worth it?

Question

I have a project that I'm working on currently using Tomcat, Spring 4, Spring Security, MySQL, and JPA w/ Hibernate.

I picked JPA from the standpoint that it's suppose to make swapping out the underlying implementation of ORM providers seamless, or at least less painful. I would say that this is mentally using the spec over the implementation (JAX-RS) is the default standpoint of the Java development community.

I'm curious if this is really a task worth doing. I'm sure if I used Hibernate directly I would gain some power because I could use features that are not part of the main JPA specification.

Part of my concern comes from the idea of YAGNI. I'm essentially programming in a specific style and fashion (using JPA instead of Hibernate) so that at some point in the future I can swap out my ORM implementation. I severely doubt that will ever happen over the life of the product, so I'm essentially putting effort into something that I'll probably never reap the benefits of.

What are your thoughts? Is "programming to the interface" worth it when it comes to stuff like JPA? Have you ever actually swapped an entire ORM implementation in a product? Have you ever been able to completely avoid the abstraction from something like JPA leaking anyways? I personally have a single native SQL call already (to clean out the database tables), and there's somethings I'd like to futz with that are built into the JPA spec (get/set prefixes to your methods, and the difference between MEMBER OF/IN, which only binding myself to an underlying implementation will get me any chance of avoiding.

Answer 1

so that at some point in the future I can swap out my ORM implementation. I severely doubt that will ever happen over the life of the product, so I'm essentially putting effort into something that I'll probably never reap the benefits of

In my experience, the typical enterprise project never swaps out:

1. Database
2. ORM
3. Language

I don't know the numbers, but the percentage of 2-tier apps I've seen implement and then change one of those things would probably be less than 10%. If it happens, it is rare, and it usually happens within the first 2-3 months of the project when people are still in discovery mode. Most systems I know are still running on their original platforms 8-10 years later.

More often than swapping out an ORM, do you want to know what I've seen more of? Removing the ORM completely to drop down to SQL due to performance issues. So no matter what, in that case, your gonna be rewriting stuff.

As far as implementation agnostic, its a myth. It really amounts to dumbing down. So my approach is to embrace the data layer. Make it a first class part of your language and design. It makes for happier, more successful projects.

Answer 2

is it worth it?
That would entirely depend on the application.
If you're writing an internal application for a single company, forget it. That database will outlive the application by years, possibly decades.
Unless of course you've been given to understand from the outset that the database is planned to be replaced by something else in the near future.
If you're writing it for sale to customers, who may have different database engines, AND the requirements are such that it's supposed to support multiple database engines, THEN it makes sense.

For most people writing Java applications then, it is largely irrelevant.

Answer 3

From my experience: no, it is not worth it in case of JPA/Hibernate.

Is "programming to the interface" worth it when it comes to stuff like JPA?

It is, but has nothing to do with JPA specifically. You can do "programming to the interfaces" of the Hibernate. This is not about hiding a framework under a standard, it is about SOLID.

Have you ever actually swapped an entire ORM implementation in a product?

Yes and no. One of our company's products partially migrated from Hibernate to jOOQ (which has nothing to do with JPA). It wasn't exactly a "typical enterprise project" which @codenheim mentioned, so swapping was possible.

I see no point of swapping Hibernate with another JPA-compliant ORM.

Have you ever been able to completely avoid the abstraction from something like JPA leaking anyways?

No. It's impossible because both JPA and Hibernate are very complex. And you have to deal with Hibernate's performance issues and design flaws anyway.

Answer 4

At the risk of sounding contrarian here, I would say, that yes, it is worth it. And it is not.

The issue is not so much in switching your ORM or database provider as such. It is more of an issue of separation of concerns and staying agile.

Once you start relying on some implementation detail of a library, you start creating deeper and deeper entanglements of concerns.

If you know hat your ORM implementation is Hibernate, this knowledge starts seeping down the whole architecture of your application. And whenever a new technology comes along that displaces Hibernate or JPA so thoroughly as Hibernate did to whatever came before it, you find that the dependencies have become much deeper than you expected.

It is much better to tuck away the entire concern of persisting your model somewhere out of the way, where all the intricacies of dealings with databases and transactions and whatnot, can be easily ignored by the rest of the application. In that remote dark corner, you can tie yourself in knots over specific implementation details if you want to -- it does not really matter any more.

Answer 5

The problem with implementation agnosticism is that you will, in your time as a developer, waste time either way.

I've written several projects which we wasted a load of time writing to an interface, which were then never used in any new way, never converted and just used 'as is' for years

I've also wasted a load of time converting software that nobody ever expected to need to be converted.

The only real observation I have to make, is that the former is a lot less painful.