java - Hibernate が短期間のセッション用に設計されているように見えるのはなぜですか?

Question

これは主観的な質問であることは承知していますが、Hibernate が短期間のセッション用に設計されているように見えるのはなぜですか? 通常、私のアプリでは、データ レイヤーを抽象化するために DAO を作成しますが、エンティティ オブジェクトがどのように使用されるか予測できないため、そのコレクションの一部が遅延ロードされるか、セッションが閉じられるとロードに失敗します。

セッションを自動的に再開するように、またはセッションを常に開いたままにするように設計しなかったのはなぜですか?

Answer 1

トランザクション境界の外に移動すると、新しいトランザクションを開始せずにデータベースに再度ヒットすることはできないためです。「万が一に備えて」トランザクションを長時間実行することは悪いことです (tm)。

ビューからオブジェクトを遅延ロードしたいと思います-いくつかのオプションについては、こちらをご覧ください。セッション ファサード メソッドによって返されるオブジェクト マップの量を正確に定義することを好みます。これにより、ビジネス層の単体テストとパフォーマンス テストが容易になります。

Answer 2

EJB と Hibernate を使用するデスクトップ アプリに取り組みました。lazy=falseオブジェクトがシリアル化されると、バックエンドからフェッチできなくなるため、あらゆる場所に設定する必要がありました。残念ながら、それがまさにその方法です。

パフォーマンスが気になる場合は、バックエンドでキャッシュを使用して、非遅延フェッチがそれほど苦痛にならないようにすることができます。

Answer 3

デスクトップアプリケーションを作成しているので、フィルターの使用は適用できません。

Answer 4

あなたが探しているのは OpenSessionInView パターンです。これは本質的に、セッションを透過的に再開する必要があるときを検出する概念的なフィルター (サーブレット フィルターとして実装されることもあります) です。いくつかのフレームワークはこれを実装しているため、自動的に処理されます。

Answer 5

Hibernate は、オブジェクトをリレーショナル データベース テーブルにマップする方法として設計されています。それはその仕事を非常にうまく成し遂げます。しかし、すべての人を常に喜ばせることはできません。初期化がどのように機能するかを学ぶには多少の複雑さがあると思いますが、コツをつかめば理にかなっています。それが必ずしもあなたを怒らせるために「設計された」ものだったのかどうかはわかりません。

非 Web アプリケーションで魔法のようにセッションを再開する場合、フレームワークを学習することの複雑さがメリットをはるかに上回ると思います。

Answer 6

接続は、使い終わったらすぐにリサイクルする必要がある希少なリソースです。接続プーリングも使用している場合は、必要なときに別のものをすばやく取得できます。これは、Web サイトをスケーリングするために使用する必要があるアーキテクチャです。たとえデスクトップ アプリであっても、それらのユース ケースはおそらくスケーラブルなサイトに集中しています。

MS ADO.NET を見ると、接続を短時間開いたままにすることに同様の焦点が当てられていることがわかります。接続を切断して更新し、準備ができたらデータベースに適用するための完全なオフライン モデルがあります。