JBoss发布Hibernate 4.0

新年第一篇博文

本文来源于我在InfoQ中文站翻译的文章，原文地址是：http://www.infoq.com/news/2012/01/hibernate-4-released

近日，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