3

Hibernate について読んbuildSessionFactoryでいると、Hibernate 4 以降では非推奨であるという警告に遭遇しました。このstackoverflowの投稿とドキュメントに従って、私はbuildSessionFactory(serviceRegistry).

しかし、なぜ廃止されたのでしょうか。古い方法よりも ServiceRegistry を使用する利点は何ですか?

4

1 に答える 1

0

詳しくはこちらをご確認ください。

現在、SessionFactory は、一連のものを Configuration オブジェクトに投入し、攪拌し、沸騰させてから、SessionFactory を引き出すことによって構築されます。深刻なことに、構成内での現在の操作方法と、それを使用して SessionFactory を構築する方法には、いくつかの問題があります。さまざまな情報が利用可能になる「ライフサイクル」がないという一般的な問題。これは多くの点で重要な省略です。

  1. スキーマ生成を検討してください。現在、多くの db オブジェクト名が決定されているときに、方言を知ることさえできません。たとえば、方言のキーワード/予約語でもあるテーブル/列名を透過的に処理できるため、これは素晴らしいことです。
  2. 型の静的性と型マッピング。現在、それらをスコープするものが何もないためです。理想的には、型インスタンスは、それがバインドされている SessionFactory を認識します。代わりに、API メソッドを何度も変更して、SessionFactory が必要であることが判明したときに渡されたパラメーターとして追加する必要があります。
  3. また、Hibernate の「静的」構成パラメーターのほとんど (すべて?) は、これらの静的型内から使用されるため、現在そうする必要があります。したがって、スコープ タイプを使用すると、これらの構成パラメーター (バイトコード プロバイダー、バイナリ ストリームの使用など) のスコープも設定できます。理想的には、ユーザーが org.hibernate.cfg.Settings (または類似のもの) インスタンスを自分で構築するスキームが起こっていると思います。さらに、何らかのレジストリにメタデータを適用します (ここでは MetadataRegistry と呼びましょう)。次に、SessionFactory を構築するために、これら 2 つの情報を提供します (ctor を介して? builder を介して?)。ただし、重要な側面は、MetadataRegistry の情報がその時点まで処理されないことです。これにより、スキーマ オブジェクトの名前、型、
于 2015-01-09T06:46:58.513 に答える