为什么buildSessionFactory()被buildSessionFactory(ServiceRegistry)取代？ ServiceRegistry的重要性是什么？
答案 0 :(得分：6)
Hibernate的Jira
解释了其原因https://hibernate.onjira.com/browse/HHH-2578
目前，SessionFactory是通过将一堆东西抛入Configuration对象，激活它，让它沸腾，然后拉出SessionFactory来构建的。严肃地说，我们当前在Configuration中运行的方式存在一些问题，以及我们如何使用它来构建SessionFactory： 一般的问题是，当各种信息可用时，没有“生命周期”。这在很多方面都是一个重要的遗漏： 1）考虑模式生成。目前，当确定很多数据库对象名称时，我们甚至无法知道方言。这将是很好的，因为它将允许我们透明地处理表/列名称，例如，方言中的关键字/保留字。 2）类型的静态和类型映射。因为我们目前没有任何东西可以限定它们。理想情况下，类型实例将知道它绑定到的SessionFactory。相反，我们现在所拥有的是在很多时候将Session方法更改为SessionFactory作为传递参数，只要发现它是必需的。 3）同样，Hibernate中的大多数（全部？）“静态”配置参数目前都需要这样，因为它们在这些静态类型中使用;因此，范围类型将允许我们也对这些配置参数进行范围化（诸如字节码提供者，二进制流的使用等）。 理想情况下，我看到的是用户自己构建org.hibernate.cfg.Settings（或类似的东西）实例的方案。此外，他们会将元数据应用于某种类型的注册表（现在让我们称之为MetadataRegistry）。然后，为了构建一个SessionFactory，他们将提供这两条信息（通过ctor？via builder？）。但重要的一点是MetadataRegistry中的信息在此之前不会被处理，这将允许我们保证解析模式对象名称，类型等可以访问运行时设置（特别是方言）< / p>
您还可以阅读有关此内容的评论：https://hibernate.onjira.com/browse/HHH-7580 复制粘贴太多了，我猜Jira不会失败所以这个答案应该是有效的。