我见过很多人在Hibernate等ORM解决方案之上编写（或使用）第三方抽象框架，以便他们可以潜在地从一种ORM引擎切换到另一种（甚至是另一种技术）。一些架构师甚至认为这样的框架是必需品。
值得赞扬，但问题比解决方案更多。当你将Hibernate等技术抽象化以使其《可移植》时，你会牺牲大量的功能和性能。仅仅是因为语义在不同引擎之间略有不同。
让我们用统计数据来玩玩
- 在1%的应用程序中，需要从一个ORM引擎切换到另一个引擎
- 在99%的应用程序中，需要ORM的一个或多个高级功能
你应该专注于使用和了解你的ORM引擎，而不是花时间编写（或使用）抽象框架。
当使用你未编写的抽象框架时，实际上会出现其他类型的问题。
当你的ORM引擎引入新的API或新功能时，你必须等待抽象框架相应地发布，这使得你依赖于他人的日程。
你不再了解（无论是通过记忆还是完全不了解）在ORM引擎之上引入的实际方法抽象（或语义变更）。这位用户就是这样学到的（而且他并不孤单），Spring的/HibernateTemplate/甚至没有给出实际语义的提示。
ORM引擎之间的唯一合适的抽象是一个它们共同遵守的规范。这就是为什么引入JPA（EJB 3.0）的原因之一。为什么它是唯一的方式？因为规范非常详细地描述了各种ORM引擎必须遵循的共同语义。
所以，请三思而后行，在使用某些随机的专有抽象框架（开源或非开源）之前。它们通常没有任何增值，但增加了错误区域... 规范是用来解决引擎抽象问题的（但再次强调，这是一个非常少数的应用程序关心的问题）。
请注意，如果有人误导，我并不是反对DAO层
