なぜbuildSessionFactory（）は非推奨ですか？

Question

なぜbuildSessionFactory()がbuildSessionFactory(ServiceRegistry)で置き換えられましたか？ ServiceRegistryの重要性は何ですか？このため

Answer 1

の理由は、HibernateのJiraの現在のSessionFactoryは、Configurationオブジェクトに原料の束を投げ、それを攪拌し、それが沸騰に来るせることによって構築されている

https://hibernate.onjira.com/browse/HHH-2578

に説明されています、 SessionFactoryを引き出します。深刻なことに、現在Configuration内で動作している方法や、SessionFactoryを構築するためにこのメソッドを使用する方法にはいくつか問題があります。 さまざまな情報が利用できるようになるまでのライフサイクルがないという一般的な問題です。これは、多くの点で重要な省略である。 1）スキーマの生成を検討する。現在多くのdbオブジェクト名が決定されているときには、方言を知ることさえできません。これは、例えば、方言のキーワード/予約語でもあるテーブル/カラム名を透過的に扱うことができるので便利です。 2）型の静的性および型マッピング。現在のところ、スコープを設定するものはありません。理想的には、型インスタンスはそれがバインドされているSessionFactoryを認識します。それどころか、私たちが今持っているのは、APIメソッドを変更して、渡されたパラメータとしてSessionFactoryを追加する必要があることが判明したときに、かなり多くの時間を費やすことです。 3）また、Hibernateの "静的な"設定パラメータの大部分（すべて？）は、これらの静的な型の中からの使用のために現在必要です。したがってスコープタイプは、これらの設定パラメータ（バイトコードプロバイダ、バイナリストリームの使用など）をスコープすることも可能にします。 理想的には、ユーザーがorg.hibernate.cfg.Settings（または何かsimiliar）インスタンスを構築するスキームです。さらに、彼らはメタデータをある種のレジストリに適用します（今のところMetadataRegistryと呼ぶことができます）。次に、SessionFactoryを構築するために、これらの2つの情報を（builder経由でctor？経由で）提供します。しかし、MetadataRegistryの情報は、その時点まで処理されないため、スキーマ・オブジェクトの名前や型などを解決するとランタイム設定（特に方言）にアクセスできることが保証されます

https://hibernate.onjira.com/browse/HHH-7580 このペーストをコピーするには余りにも多く、Jiraはダウンしないので、この回答は有効であるはずです。