Java Hibernate或JDBC

我有一个厚客户端java swing应用程序，它的模式是25个表和15个JinternalFrame（表的数据输入表单）。我需要为DBMS交互选择直接的JDBC或ORM（在本例中是带有spring框架的hibernate）。应用程序的构建将在将来进行

对于这样一个规模的项目来说，hibernate是不是太过了？如果您能解释一下答案是或否，我们将不胜感激（如果有必要，甚至可以采用不同的方法）

---

TIA。

Hibernate可能很好，但它和其他JPA ORM往往在一定程度上决定了您的数据库结构。例如，复合主键可以在Hibernate/JPA中完成，但它们有点笨拙。还有其他例子

如果您对SQL感到满意，我强烈建议您看看。它可以完成Hibernate 90%以上的功能，但实现起来要简单得多

我想不出一个理由为什么我会选择纯JDBC（甚至SpringJDBC）而不是Ibatis。休眠是一个更复杂的选择

---

看看。

我认为两者都是不错的选择，但就我个人而言，我会使用hibernate。我不认为hibernate对于这样一个规模的项目来说是过分的

Hibernate真正吸引我的地方是处理实体/表之间的关系。如果您同时处理修改父项和子项（孙子、兄弟姐妹等），那么手工执行JDBC可能需要大量代码。Hibernate可以轻松实现这一点（通常只保存一次父实体就足够了）

---

不过，在处理Hibernate时肯定会有一些复杂性，比如理解会话刷新的工作原理，以及处理延迟加载。

简单的JDBC最适合最简单的情况

如果您想留在Java和OOD中，那么应该选择Hibernate或Hibernate/JPA或任何其他JPA提供者/JPA

如果您更熟悉SQL，那么使用Spring for JDBC模板和其他面向SQL的框架不会有什么坏处

---

相比之下，除了事务控制之外，在使用JPA时使用Spring并没有多大帮助。

毫无疑问，Hibernate有其复杂性

但我真正喜欢Hibernate方法（还有一些其他方法）的地方是，您可以在Java中获得更好的概念模型。虽然我不认为OO是万灵药，也不寻求设计在理论上的纯洁性，但我发现很多次OO确实简化了我的代码。正如您特别询问的详细信息，以下是一些示例：

• 增加的复杂性不在模型和实体中，而是在操作所有实体的框架中。对于维护人员来说，最困难的部分不是几个框架类，而是您的模型，因此Hibernate允许您保持最干净的部分（模型）

• 如果在所有实体中都使用了字段（如id或审核字段等），则可以使用它创建一个超类。因此：
  • 您编写的代码更少，但更重要的是
  • 模型中的概念较少（唯一的概念在代码中是唯一的）
  • 您可以免费编写更通用的代码，该代码随实体提供（未知、无类型转换或强制转换），允许您访问id
• Hibernate还有许多特性来处理您可能需要的其他模型特性（现在或以后，只在需要时添加它们）。将其视为设计的可扩展性质量
  • 您可以用组合（多个实体具有相同的成员，其中包含多个实体中碰巧需要的几个相关字段）替换继承（子类化）
  • 您的几个实体之间可能存在继承关系。通常情况下，您有两个结构几乎相同的表（但您不希望将所有数据存储在一个表中，因为这样会使引用完整性丢失到另一个父表）
• 通过实体之间的重用（但只有适当的继承和组合），通常会带来一些额外的优势。示例：
  • 通常有一些方法可以读取相似但不同的实体的数据。假设我读取了三个实体的“title”字段，但对于某些实体，如果结果为null，我将使用不同的默认值替换结果。很容易拥有一个签名“getActualTitle”（在超类或接口中），并在这三个实现中实现默认值处理。这意味着我实体中的代码只处理“实际标题”的概念（我明确了这个函数概念），方法继承负责执行正确的代码（没有更多的切换或if，没有代码重复）
• 随着时间的推移，需求不断变化。您的数据库结构将出现问题。单独使用JDBC时，对数据库的任何更改都必须影响代码（即双倍成本）。使用Hibernate，可以通过只更改映射而不是代码来吸收许多更改。反过来也会发生同样的情况：Hibernate允许您更改代码（例如在不同版本之间），而无需更改数据库（更改映射，尽管它并不总是足够）。总之，Hibernate允许您独立地开发数据库和代码

---

出于所有这些原因，我会选择Hibernate:-）

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

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

今天我不太确定

Hibernate（和JPA）在某些方面非常有用，尤其是在开发周期的早期。 使用Hibernate比使用JDBC要快得多。 你可以免费获得很多功能-cach