Hibernate での Open Session in View (OSIV) は悪い習慣ですか? 代替策は何ですか?

Hibernate で View でセッションを開くのは悪い習慣である理由

View でセッションを開く (OSIV) は、Hibernate のパターンであり、セッションは HTTP リクエスト全体を通じて開かれます。これは LazyLoadExceptions を回避するには有益であるように見えますが、多くの欠点が生じます。

データベース パースペクティブの問題:

• 自動コミット モード:トランザクションはサービス層によってコミットされますが、OSIV では明示的にコミットされないため、UI レンダリングからの後続のデータベース ステートメントは、OSIV で実行されます。自動コミットモード。これにより、頻繁なトランザクション ログのフラッシュが必要となり、データベース サーバーに負担がかかります。
• 混合ステートメント ソース: OSIV では、サービス層と UI レンダリング プロセスの両方でステートメントを生成できるため、テストが困難になります。レイヤー間のデータベースの相互作用。

コードの複雑さとスケーラビリティ問題:

• 制限された UI 機能: OSIV は UI レイヤーを関連付けのナビゲーションに制限しており、N 1 個のクエリの問題を引き起こす可能性があります。
• 接続holding: OSIV は UI レンダリング全体にわたってデータベース接続を保持することがあり、接続のリース時間を増やし、接続のリース時間を短縮します。トランザクション スループット。

Spring Boot の考慮事項:

Spring Boot では、OSIV がデフォルトで有効になっています。アプリケーション構成で spring.jpa.open-in-view=false を設定して無効にすることをお勧めします。

LazyLoadExceptions を回避するための代替戦略:

の代わりにOSIV、次のことを考慮してください:

• 熱心なフェッチ関係: ビュー層に必要な関連付けを積極的に取得し、エンティティの取得時に確実にロードされます。
• サービス層での明示的な取得: fetch() などのメソッドを使用して、ビューをレンダリングする前に関連付けを明示的に取得します。
• 射影: 射影を使用して、ビュー レイヤに必要なデータのみを取得し、不必要な遅延初期化を回避します。
• Criteria API: Criteria API を利用して、クエリと積極的なフェッチの関連付けをカスタマイズします。
• エンティティ グラフ: エンティティ グラフを定義して、特定の用途に基づいて関連付けの取得を最適化します。場合。

以上がHibernate での Open Session in View (OSIV) は悪い習慣ですか? 代替策は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。