OpenSessionInViewとPersistentContext（Extended）

Question

私はアーキテクチャのHibernate/JPA/Spring/Zkで作業しています。私は多くのフレームワークを学ばなければならないので、これらの質問は最近増えています。

私は数日間困惑しています。

「パターン」OpenSessionInViewについては、レイジーロードを行うためにHibernateトランザクションを生かし続けると聞いています。 多くの人はパターンがあまりきれいではないとも言います。

そしてもう1つは、PersistentContext拡張はスレッドセーフではないと言われており、entityManagerを生かしておくのには適していません。

したがって、これらの問題に対する真の解決策は何ですか？ 私は、これらの問題は、特に必要なときに重いコレクションを読み込むために遅延ロードを使用すると、より多くの可能性を可能にするajaxの導入から生じると推測します。

私は@PersistenceContextを拡張モードで試しました。それは働いています... 私は自分のJUnitテスト用に設定しなければなりませんでした。それ以上の設定をせずに遅延ロードを使ってWebアプリケーションでも動作しています。

フレームワーク（Spring、JPA 2.0）の進化は、PersistentContextでより簡単でよりクリーンな作業であることを意味していますか？

これが当てはまらない場合は、SpringのOpenSessionInViewFilterを使用して、トランザクションモードでPersistentContextを置き換える必要がありますか？

ありがとうございます。

Answer 1

お聞きします。私は2008年以来、いくつかのアプリケーションで両方のパターンを実装しました。今、私はすべてのパターンのパターンを断念します。クライアントに状態を導入すると、スケーラビリティと状態管理の問題が発生します。つまり、クライアントでマージしますか、ユーザーセッションで保存しますか、保存する前にオブジェクトが一時的である必要があります。クライアントとサーバサイドの状態をどのように同期させますか？ dbが変更されたときに何が起こるのですか - クライアントは中断しますか？

Spring MVCを含む既存の技術の動向を見てみましょう：パターンは2つのプロジェクトを構築することです：1）安らかなWebサービス2）ユーザーインターフェース。状態は不変のドメインモデルによって共有されます。確かにあなたはdtosのセットを維持するかもしれませんが、それらは予測可能で、安価で、無限に拡張できます。

私の推奨はありますか？ワイヤオーバーでプロキシされたオブジェクトを送信したり、クライアント上のdtosを処理したり、サーバー側の検証を再利用する場合は、クライアントとドメインモデルを共有したりしないでください。レイジーコレクションは、Ajaxを介してきめ細かなAPIコールを介してロードできます。こうすることで、クライアントに完全な制御を与えることができます。

これは、過去5年間にソーシャルウェブの規模がどのように変化したかを示しています。