休眠或 JDBC

好问题，没有一个简单的答案。

我曾经是Hibernate的忠实粉丝，在多年的多个项目中使用它。我曾经认为任何项目都应该默认休眠。

今天我不太确定。

Hibernate（和JPA）在某些方面非常有用，尤其是在开发周期的早期。使用Hibernate比使用JDBC要快得多。您可以免费获得许多功能 - 缓存，乐观锁定等。

另一方面，它有一些隐性成本。冬眠在你开始时非常简单。遵循一些教程，在你的课堂上添加一些注释 - 你已经有了自己的毅力。但它并不简单，并且能够在其中编写良好的代码需要对其内部工作原理和数据库设计有很好的了解。如果您刚刚开始，您可能不知道以后可能会咬住您的一些问题，因此这里有一个不完整的列表。

性能

运行时性能足够好，我还没有看到休眠是生产中性能不佳的原因的情况。问题在于启动性能以及它如何影响单元测试时间和开发性能。当休眠加载时，它会分析所有实体并执行大量预缓存 - 对于不是很大的应用程序，可能需要大约5-10-15秒。所以你的1秒单元测试现在需要11秒。不好玩。

数据库独立性

它非常酷，只要你不需要对数据库进行一些微调。

内存中会话

对于每个事务，休眠将在内存中存储一个对象，用于它“接触”的每个数据库行。当您进行一些简单的数据输入时，这是一个很好的优化。但是，如果出于某种原因需要处理大量对象，则可能会严重影响性能，除非您自己显式且仔细地清理内存中会话。

叶 栅

级联允许您简化对象图的使用。例如，如果您有一个根对象和一些子对象，并且您保存了根对象，则可以配置休眠以保存子对象。当对象图变得复杂时，问题就开始了。除非你非常小心，并且对内部发生的事情有很好的了解，否则很容易搞砸这件事。当你这样做时，很难调试这些问题。

延迟加载

延迟加载意味着每次加载对象时，休眠不会加载所有相关对象，而是提供占位符，只要您尝试访问它们，就会立即解析这些占位符。伟大的优化吧？是的，除了您需要注意此行为，否则您将获得神秘的错误。以Google“LazyInitializationException”为例。并注意性能。根据加载对象和对象图的顺序，您可能会遇到“n +1选择问题”。谷歌它以获取更多信息。

模式升级

Hibernate允许通过重构java代码并重新启动来轻松更改模式。当你开始时，这很棒。但是，您发布了第一个版本。除非您想失去客户，否则您需要为他们提供架构升级脚本。这意味着没有更简单的重构，因为所有架构更改都必须在SQL中完成。

视图和存储过程

休眠需要对它所处理的数据具有独占写入访问权限。这意味着您不能真正使用视图、存储过程和触发器，因为这些可能会导致数据发生更改，而休眠状态并不知道它们。您可以让一些外部进程在单独的事务中将数据写入数据库。但是，如果这样做，您的缓存将包含无效数据。这是另一件需要关心的事情。

单线程会话

休眠会话是单线程的。通过会话加载的任何对象只能从同一线程访问（包括读取）。这对于服务器端应用程序是可以接受的，但如果您正在执行基于 GUI 的应用程序，则可能会使不必要的事情复杂化。

我想我的观点是没有免费的饭菜。

Hibernate是一个很好的工具，但它是一个复杂的工具，它需要时间来正确理解它。如果您或您的团队成员没有这样的知识，那么对于单个应用程序使用纯JDBC（或Spring JDBC）可能会更简单，更快捷。另一方面，如果你愿意花时间学习它（包括通过实践和调试来学习），那么将来你将能够更好地理解权衡。

休眠可能很好，但它和其他JPA ORM倾向于在一定程度上决定你的数据库结构。例如，复合主键可以在Hibernate / JPA中完成，但它们有点尴尬。还有其他例子。

如果你对SQL感到满意，我强烈建议你看看Ibatis。它可以完成Hibernate的90%以上的工作，但在实现上要简单得多。

我想不出为什么我会选择直接的JDBC（甚至是Spring JDBC）而不是Ibatis。休眠是一个更复杂的选择。

看看Spring and Ibatis Tutorial。