5

私はアーキテクチャ Hibernate/JPA/Spring/Zk に取り組んでいますが、フレームワークをたくさん学ばなければならないので、最近は質問を増やしています。

数日間頭を悩ませている質問があります。

Hibernate トランザクションを維持して遅延読み込みを行う「パターン」 OpenSessionInView について聞いたことがあります。また、模様がきれいではないという声も多くあります。

一方、拡張された PersistentContext はスレッドセーフではないため、entityManager を存続させるのには適していないと言われています。

では、これらの問題に対する本当の解決策は何ですか? これらの問題は、特に必要に応じて重いコレクションをロードするために遅延ロードを使用することで、より多くの可能性を可能にする ajax の導入から生じると思います。

とりあえず、 @PersistenceContext を拡張モードで試してみました。動作しています... JUnit テスト用に設定する必要がありましたが、それ以上の構成なしで遅延読み込みを使用して Web アプリケーションでも動作しています。

フレームワーク (Spring、JPA 2.0) の進化は、PersistentContext での作業がより簡単になり、より「クリーン」になったことを意味しますか?

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

ありがとうございました。

4

1 に答える 1

1

私はあなたを聞く。私は 2008 年以来、いくつかのアプリケーションで両方のパターンを実装してきました。クライアントに状態を導入すると、スケーラビリティと状態管理の問題が発生します。クライアントでマージするか、ユーザー セッションで保存するか、ウィザードを実行するとどうなるか、オブジェクトは保存前に一時的でなければなりませんか? クライアントとサーバー側の状態をどのように同期しますか? データベースが変更されるとどうなりますか? クライアントは壊れますか?

Spring MVC を含む既存のテクノロジーの傾向を見てください。パターンは 2 つのプロジェクトを構築することです: 1) 安らかな Web サービス 2) ユーザー インターフェイス。状態は、不変のドメイン モデルを通じて共有されます。確かに一連の dtos を維持することになるかもしれませんが、それらは予測可能で、安価で、無限に拡張できます。

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

それが、過去 5 年間でソーシャル Web が拡大した方法です。

于 2012-10-29T16:50:05.397 に答える