JBoss 发布 Hibernate 4.0

近日， JBoss 发布了流行的对象 / 关系（O/R）映射框架 Hibernate 4 。Hibernate 4 主要的新特性如下所示：

• 多租户架构支持
• 引入了“Services”API
• 提供了更棒的日志，支持 i18n 与消息编码（通过 JBoss Logging 而非 slf4j ）
• 为 OSGi 支持做好了准备
• 清理并删除了几处废弃代码

所谓多租户架构，就是将大型的企业应用划分为虚拟的多个客户端 / 客户（又叫做租户）而不必将所有数据放在一个共享空间中。该原则改进了管理、监控，甚至是安全，对于大型的服务提供商来说非常有帮助。提供云基础设施的公司也会从多租户架构中获益颇丰。该原则有几种实现方式，列举如下：

1. 每个客户端 / 租户使用不同的数据库与 / 或模式
2. 所有客户端使用相同的数据库 / 模式，但所有表中都有一个附加的列（比如说 tenant_id），用于过滤数据

Hibernate 4.0支持上述第1 种方式，并且计划在下一个版本中支持第2 种方式（也就是区分多个租户）。

Hibernate 中新增的另一个重要特性就是“Services”API 规范。除了标准的内建服务外，你还可以通过该 API 以其他几种方式扩展 Hibernate。现在已经有了几种方式可以插入到 Hibernate 内核中，但 Service API 则提供了一种标准方式来实现这一点。近日，InfoQ 有幸采访到了 Hibernate 项目领导 Steve Ebersole 以深入了解这些新特性：

InfoQ：你能否谈谈“Services”的概念呢？他们只能用于 Hibernate 扩展么，对于应用开发者来说有何价值呢？

首先，我觉得大家应该认识到有很多应用开发者在每天的应用开发中也会开发 Hibernate 扩展。如果你开发自定义事件监听器、自定义类型等等，那么你就在开发 Hibernate 扩展。这种情况很常见。 你可以将 Services API 看作是小型、领域特定的 CDI，提供对常见行为的统一处理，需要诸如生命周期、依赖、JMX 管理等。因此从这个角度来说，开发者会很频繁地开发 Services。一个简单的示例就是某个事件监听器想要向 JMS 中写入。我可以将 JMS 看作是一个 Service，因为其他监听器或是自定义扩展都可能会用到该 JMS 连接。

但 Services 是无限多的。难道“应用代码”会查找并直接使用 Services 么？不，通常不是这样。但这并不意味着每个人都会这么看。还是回到方才的 JMS 用例，我可以确定地说应用代码也需要与该 JMS 连接交互。这样，它就可以从 Hibernate 中查找该 JMS 连接。基本上，它会使用 Hibernate 管理整个生命周期。

InfoQ：OSGi 对于你来说有多重要？Hibernate 距离完整支持 OSGi 还有多远呢？

这个问题很有意思。根据我的经验，在我们真的开始推进时，很多人会问“OSGi 支持”或“OSGi 兼容”对于他们到底意味着什么，他们要么不知道，要么就是答非所问。我觉得这应该是双重的： 首先，Hibernate 能否处理 OSGi 环境下的模块化类加载？毫无疑问，在 4.0 前这是很棘手的，因为之前的 Hibernate 使用了一个非常传统的 ClassLoader 设置。在 4.0 中，ClassLoaderService 成为标准服务之一，它定义了 Hibernate 查找类与资源的方式，以及如何解析标准的 Java ServiceLoaders。本质上，它定义了一个 API，通过 class-path 处理 Hibernate 的所有交互。更为重要的是，它是通过一种可交换的方式来定义的。其意图在于非传统的类加载环境可以交换他们自己的策略来决定 Hibernate 该如何与 ClassLoaders 交互。这已经在 JBoss AS 中得到了充分的测试，测试中使用了自定义的 ClassLoaderService 来与模块化类加载进行交互。因此从这个角度来说，Hibernate 已经实现了目标。

其次，就导入 / 导出来说，Hibernate 是如何定义自己的“OSGi 元数据”？目前，Hibernate 并未在其任何 jar 中定义特定于 OSGi 的元数据。如果有人做了这方面的贡献，我们就会将其纳入进来。要知道的是 Hibernate 团队中没有人是 OSGi 专家。这应该由熟悉 OSGi 元数据的相关人士来实现。我们在 4.0 中所做的是将包划分开来以便向感兴趣的人们表明立场，如果我理解的没错，那么这些人应该担负起这个责任。

InfoQ：日志框架为何发生了变化？

在 Hibernate 4 开发伊始，我们就决定要在日志中加入对 i18n 的支持。在那时就我们所知，JBoss Logging 是唯一一个完整支持 i18n（包括参数化）的日志库。其 i18n 支持更加类似于 GNU gettext ，相对于更加 Java 化的 ResouceBundle 方式，Hibernate 开发团队一致认为 JBoss Logging 的方式更好。JBoss Logging 的异常消息也支持 i18n（通过常见的方式实现），但我们并没有用到这个功能。 此外，JBoss Logging 还包含了对消息键的内建支持，它将消息键作为独立的概念而非 ResourceBundle 中的键，以此来实现 i18n。这是个不可改变的键，与导致日志消息的情况相关联。这个概念非常适合于围绕着这些键来构建 FAQ 和文档。没错，你可以直接通过 SLF4J、Java Util Logging 等做到这一点。但从工具的角度来看，我认为这些键应该成为一等公民。对于充斥了很多日志的大型项目来说，你真的要能够确保这些键是唯一且一致的。JBoss Logging 也做到了这一点。

InfoQ：有些人可能会说这些新特性几乎都是内部的。这是否意味着 Hibernate 已经成熟了，不需要再添加用户能够直观看到的一些变化了？Hibernate 是否已经进入了“维护”模式了呢？

当然不是了，虽然我们没有添加新的特性，但 Hibernate 并没有进入到维护模式。它需要维护么？当然了。不知道是否有人注意到，Hibernate 已经 10 岁多了。我们已经贴了不少创可贴，我觉得在计划并开发新特性时，我们不应该在创可贴上继续贴新的创可贴了。Hibernate 生长自 YAGNI 设计原则，随着时间的流逝，契约 /API 概念将会变得自然而明显。他们也将不断发展。 我觉得目前只有为数不多的 Java OSS 项目能够像 Hibernate 那样长久以来保持成功状态，这些成功的框架都会经历一个或多个大的重构期。

InfoQ：Hibernate 5 有哪些值得期待的特性呢？当前的开发目标是什么？

5.0 的主要目标在于重新设计 Hibernate O/R 元数据的模型，包括 XML 和注解。这些代码来自 Hibernate 最初的需要。来自 JPA 的的新需求或特性将会构建于其上。这么做的主要原因在于很多项目都使用了这些类，我们想要降低对这些项目的破坏。但说实在的，重新思考这些模型已经有些晚了。

Java artifacts 已经位于 Maven Central 中了，可见 Hibernate 4 已经为进入到 Java 应用中做好了准备。

查看英文原文： JBoss Releases Hibernate 4.0