保持与实现不可知论真的值得吗？

我有一个正在使用Tomcat，Spring 4，Spring Security，MySQL和带有Hibernate的JPA的项目。

我从JPA的角度出发选择了JPA，它是为了使ORM提供程序的基础实现无缝交换，或者至少减轻痛苦。我要说的是，在思想上使用规范而非实现（JAX-RS）是Java开发社区的默认观点。

我很好奇这是否真的值得一做。我敢肯定，如果我直接使用Hibernate，我会获得一些力量，因为我可以使用不属于主要JPA规范的功能。

我的部分担忧来自YAGNI的想法。我本质上是以特定的样式和方式编程（使用JPA而不是Hibernate），以便将来可以在某些时候换出我的ORM实现。我严重怀疑这种情况会在产品的整个生命周期内发生，因此，我实质上是在努力做一些我可能永远不会从中受益的事情。

你怎么看？对于诸如JPA之类的东西，“编程接口”是否值得？您是否曾经在产品中交换过整个ORM实施？您是否曾经能够完全避免像JPA这样的泄漏引起的抽象？我个人已经有一个本地SQL调用（以清理数据库表），并且我想在JPA规范中内置一些功能（获取/设置方法的前缀，以及MEMBER OF之间的区别） / IN，它只会将自己绑定到底层实现上，这给了我避免的机会。

这样在将来的某个时候我可以换掉我的ORM实现。我严重怀疑这种情况会在产品的整个生命周期内发生，因此，我实质上是在努力工作，以致我永远都无法从中受益。

以我的经验，典型的企业项目永远不会掉出：

1. 数据库
2. ORM
3. 语言

我不知道这些数字，但是我所看到的实施并更改其中之一的2层应用程序的百分比可能不到10％。如果发生这种情况，这种情况很少见，通常会在人们仍处于发现模式的情况下，在项目的前2-3个月内发生。我知道，大多数系统在8-10年后仍可以在其原始平台上运行。

与换出ORM相比，您是否想更多地了解我所看到的内容？由于性能问题，完全删除ORM以便使用SQL。因此，无论哪种情况，您都将重写内容。

就实现不可知，这是一个神话。这确实意味着愚蠢。因此，我的方法是拥抱数据层。使它成为您的语言和设计的一流部分。它使项目更幸福，更成功。

这值得么？
那将完全取决于应用程序。
如果您要为单个公司编写内部应用程序，请不要理会。该数据库将在数年（甚至数十年）内使应用程序失效。
当然，除非从一开始就让您了解数据库计划在不久的将来被其他数据库替换。
如果您将其编写为出售给可能具有不同数据库引擎的客户，并且要求满足它应该支持多个数据库引擎的要求，那么就有意义了。

那么，对于大多数编写Java应用程序的人来说，这是无关紧要的。

根据我的经验：不，在JPA / Hibernate中不值得。

对于诸如JPA之类的东西，“编程接口”是否值得？

是的，但与JPA无关。您可以对Hibernate进行“接口编程”。这不是关于根据标准隐藏框架，而是关于SOLID。

您是否曾经在产品中交换过整个ORM实施？

是的，没有。我们公司的产品之一从Hibernate迁移到jOOQ（与JPA无关）。@codenheim并不完全是“典型的企业项目”，因此可以进行交换。

我看不出将Hibernate与另一个符合JPA的ORM交换的意义。

您是否曾经能够完全避免像JPA这样的泄漏引起的抽象？

不，这是不可能的，因为JPA和Hibernate都非常复杂。无论如何，您都必须处理Hibernate的性能问题和设计缺陷。

在这里冒着逆势的风险，我会说，是的，值得。事实并非如此。

问题并不仅仅是切换您的ORM或数据库提供者。这更多的是关注点分离和保持敏捷的问题。

一旦开始依赖库的某些实现细节，就开始创建越来越深的关注点纠缠。

如果您知道您的ORM实现是Hibernate，那么这种知识就会渗入您的应用程序的整个体系结构。而且，只要出现了像Hibernate所做的那样彻底取代Hibernate或JPA的新技术，您就会发现依赖关系变得比您预期的要深得多。

最好不要考虑将模型持久保存在一个地方的整个问题，在该地方应用程序的其余部分很容易忽略所有复杂的数据库和事务处理以及诸如此类的事情。在那个偏僻的黑暗角落，如果您愿意，可以将自己束缚在特定的实现细节上，这不再重要了。

与实现不可知论有关的问题是，作为开发人员，您会浪费时间的任何一种方式。

我已经写了几个项目，我们浪费了很多时间写接口，然后这些年从来没有以任何新方式使用过，从未转换过，只是多年来一直按原样使用

我还浪费了很多时间转换软件，没人期望过需要转换。

我唯一需要做的真实观察是，前者的痛苦要小得多。