ORM Technologies与JDBC？

我的问题是关于ORM和JDBC技术，与JDBC和其他方式相比，您决定使用ORM技术的标准是什么？

谢谢。

Answer 1

复杂。

ORM如果您的应用程序是域驱动的，并且对象之间的关系很复杂，或者您需要使用此对象来定义应用程序的function。

JDBC / SQL如果您的应用程序非常简单，只是直接从数据库中显示数据，或者它们之间的关系很简单。

Martin Fowler撰写的“企业应用程序架构模式”一书更好地解释了这两种类型之间的差异：

请参阅： 域模型和事务脚本

Answer 2

JDBC

1. 使用JDBC，开发人员必须编写代码以将对象模型的数据表示映射到关系数据模型及其相应的数据库模式。
2. 使用JDBC，开发人员可以使用代码行手动处理Java对象与数据库表的自动映射，反之亦然。
3. JDBC仅支持本机结构化查询语言（SQL）。 开发人员必须找出访问数据库的有效方法，即从多个查询中选择有效查询来执行相同的任务。
4. 使用JDBC处理具有大量数据库特定代码的持久数据（数据库表）的应用程序。 写入映射表数据到应用程序对象的代码（反之亦然）实际上是将表字段映射到对象属性。 随着表的更改或数据库的更改，更改对象结构以及更改写入映射表到对象/对象到表的代码至关重要。
5. 使用JDBC，开发人员有责任处理JDBC结果集并通过代码将其转换为Java对象，以便在应用程序中使用此持久数据。 因此，使用JDBC，Java对象和数据库表之间的映射是手动完成的。
6. 使用JDBC，通过手动编码来维护缓存。
7. 在JDBC中，没有检查是否每个用户都有更新的数据。 必须由开发人员添加此检查。

---

冬眠。

1. Hibernate是灵活而强大的ORM解决方案，用于将Java类映射到数据库表。 Hibernate本身使用XML文件来处理这种映射，因此开发人员不需要为此编写代码。
2. Hibernate提供透明的持久性，开发人员不需要显式编写代码，以便在与RDBMS交互时将数据库表元组映射到应用程序对象。
3. Hibernate提供了一种function强大的查询语言Hibernate Query Language（独立于数据库类型），以熟悉的SQL语法表达，并包含对多态查询的完全支持。 Hibernate还支持本机SQL语句。 它还选择了一种有效的方法来为应用程序执行数据库操作任务。
4. Hibernate本身就提供了这种映射。 表和应用程序对象之间的实际映射是在XML文件中完成的。 如果数据库或任何表中有更改，则只需要更改XML文件属性。
5. Hibernate通过维护对象表映射本身来减少代码行，并以Java对象的forms将结果返回给应用程序。 它使程序员免于手动处理持久数据，从而减少了开发时间和维护成本。
6. Hibernate，具有透明持久性，缓存设置为应用程序工作空间。 作为查询的结果，关系元组被移动到此缓存。 如果客户端应用程序为同一次写入多次读取相同数据，则可以提高性 自动透明持久性允许开发人员更多地关注业务逻辑而不是此应用程序代码。
7. Hibernate使开发人员能够为应用程序定义版本类型字段，由于这个定义的字段Hibernate每次将关系元组以Java类对象的forms更新到该表时更新数据库表的版本字段。 因此，如果两个用户检索相同的元组然后修改它并且一个用户将这个修改过的元组保存到数据库，那么Hibernate会自动为这个元组更新版本。 当其他用户尝试将更新的元组保存到数据库时，它不允许保存它，因为该用户没有更新的数据。

Answer 3

它还取决于学习曲线。

如果您对使用JPA注释进行映射（@ Entity，@ Table，@ OneToMany等）感到满意，则Ebean ORM具有相当低的学习曲线（简单的API，简单的查询语言）。

Answer 4

我想你忘了看“function关系映射”

我总结说：

• 如果您想专注于数据结构，请使用像JPA / Hibernate这样的ORM
• 如果您想了解治疗方法，请查看FRM库：QueryDSL或Jooq
• 如果需要将SQL请求调整到特定数据库，请使用JDBC和本机SQL请求

各种“关系映射”技术的优势在于可移植性：确保您的应用程序可以在大多数ACID数据库上运行。 否则，当您手动编写SQL请求时，您将处理各种SQL方言之间的差异。

当然，您可以限制自己使用SQL92标准（然后执行一些function编程），或者您可以使用ORM框架重用一些函数编程概念。

ORM强项是在会话对象上构建的，可以作为瓶颈：

1. 只要底层数据库事务正在运行，它就会管理对象的生命周期。
2. 它在您的java对象和数据库行之间保持一对一的映射（并使用内部缓存来避免重复的对象）。
3. 它会自动检测关联更新和要删除的孤立对象
4. 它处理乐观或悲观锁定的并发问题。

然而，它的优势也是它的弱点：

1. 会话必须能够比较对象，因此您需要实现equals / hashCode方法但对象的相等性必须以“业务键”为根，而不是数据库ID（新的瞬态对象没有数据库ID！）。 但是，一些具体化的概念没有业务相等（例如操作）。 常见的解决方法依赖于往往会扰乱数据库管理员的GUID。

2. 会话必须间谍关系更改，但其映射规则会推动使用不适合业务算法的集合。 有时你想使用HashMap但是ORM会要求密钥是另一个“Rich Domain Object”而不是另一个轻量级对象……那么你必须在富域域对象上实现对象相等作为一个关键…但你不能因为这个对象在商业世界中没有对应物。 因此，您将回到一个必须迭代的简单列表（并且会导致性能问题）

3. ORM API有时不适合实际使用。 例如，真实世界的Web应用程序尝试通过在获取数据时添加一些“WHERE”子句来强制执行会话隔离…然后“Session.get（id）”不够用，您需要转向更复杂的DSL（ HSQL，Criteria API）或返回本机SQL

4. 数据库对象与专用于其他框架的其他对象（如OXM框架=对象/ XML映射）冲突。 例如，如果您的REST服务使用jackson库来序列化业务对象。 但这个jackson确切地映射到了一个Hibernate One。 然后你要么合并两者，你的API和你的数据库之间会出现强大的耦合。或者你必须实现一个翻译，你从ORM保存的所有代码都丢失了……

另一方面，FRM是“对象关系映射”（ORM）和本机SQL查询（使用JDBC）之间的权衡

解释FRM和ORM之间差异的最佳方法是采用DDD方法。

• 对象关系映射支持使用“富域对象”，它是在数据库事务期间状态可变的Java类
• function关系映射依赖于“不良域对象”，这是不可变的（因此每次要更改其内容时都必须克隆一个新的）

它释放了对ORM会话的约束，并且大部分时间都依赖于SQL上的DSL（因此可移植性并不重要）但另一方面，您必须查看事务详细信息，并发问题

List persons = queryFactory.selectFrom（person）.where（person.firstName.eq（“John”），person.lastName.eq（“Doe”））。fetch（）;