阅读有关 Hibernate 的信息时，我发现警告 buildSessionFactory 在 Hibernate 4 及更高版本中已被弃用。根据this stackoverflow 帖子和docs，我使用了buildSessionFactory(serviceRegistry)。
但为什么它被弃用了？与旧方式相比，使用 ServiceRegistry 有什么优势？
【问题讨论】：
AnnotationConfiguration。
标签： java hibernate deprecation-warning
详情请查看here。
目前，SessionFactory 是通过将一堆东西扔到 Configuration 对象中，搅拌它，让它沸腾，然后拉出 SessionFactory 来构建的。严肃地说，我们目前在配置中的操作方式以及我们如何使用它来构建 SessionFactory 存在一些问题： 没有“生命周期”来确定何时各种信息可用的普遍问题。这在很多方面都是一个重要的遗漏：
- 考虑架构生成。目前，在确定大量 db 对象名称时，我们甚至不知道方言。这会很好，因为它可以让我们透明地处理表/列名，例如，它们也是方言中的关键字/保留词。
- 类型和类型映射的静态性。因为我们目前没有什么可以确定它们的范围。理想情况下，类型实例会知道它绑定到的 SessionFactory。相反，我们现在要做的是在相当多的时间更改 API 方法，以便在发现需要它时将 SessionFactory 作为传递参数添加。
- 此外，Hibernate 中的大多数（全部？）“静态”配置参数目前都需要这样做，因为它们在这些静态类型中使用；因此，范围类型将允许我们还范围那些配置参数（如字节码提供者、二进制流的使用等）。理想情况下，我看到的情况是用户自己构建 org.hibernate.cfg.Settings （或类似的东西）实例的方案。此外，他们会将元数据应用于某种注册表（现在我们称之为 MetadataRegistry）。然后为了构建 SessionFactory，他们将提供这两条信息（通过 ctor？通过 builder？）。但重要的方面是 MetadataRegistry 中的信息直到那个时间点才会被处理，这将允许我们保证解析模式对象名称、类型等可以访问运行时设置（特别是方言）
【讨论】：