2

ユーザーが項目 (私の場合、彼が取り組んでいるプロジェクト) を選択するドロップダウン メニューがあります。Web ページに表示されるほとんどのデータは、その選択に依存します。そのため、選択したプロジェクトに依存するデータベース クエリを実行する EJB Bean を呼び出すビュー スコープ Bean がいくつかあります。

データベースクエリを減らすためにそのデータのほとんどをキャッシュしたいのですが、ユーザーがプロジェクトを変更すると、変更が発生したことを他の Bean に通知する必要があり、新しいデータをフェッチする必要があります。

だから私はアイデアを持っていた：

  • projectChangeManager (セッション スコープのマネージド Bean) は、選択されているプロジェクトを保存し、プロジェクトが変更されたときにサブスクライバーに通知します。オブザーバーをクリーンアップする @PreDestory メソッドが実装されています。

  • プロジェクト オブザーバー (範囲指定されたマネージド Bean を表示)、プロジェクトの選択に基づいて EJB からデータを取得、EJB から新しいデータを取得する onProjectChange() メソッドがあります。projectChangeManager.detach(this) を呼び出して projectChangeManager から登録解除する @PreDestory メソッドが実装されています。

これはJSFでの合理的なアプローチですか? または、オブザーバー パターンを実装しないほうがよいのですが、ユーザーがプロジェクトを変更したときに、キャッシュされたすべてのデータをフェッチしてセッション Bean に保存し、ViewScoped Bean で SessionScoped Bean からそのデータにアクセスするだけですか? それとももっと良い方法がありますか？

4

1 に答える 1

1

私には、これはオーバーエンジニアリングのように見えます。最初は、すべてのマネージド Bean がデータを必要とするたびにリポジトリ/EJB を呼び出せるようにするだけでした。次に、永続レイヤー (JPA/Hibernate/使用するもの) でのキャッシュに依存します。

これがパフォーマンスの問題であることが判明した場合は、手作業によるキャッシング ソリューションを検討できます。

その場合でも、オブザーバーアプローチの利点はまだよくわかりません。2 番目のアプローチ (セッション Bean のキャッシュ、ViewScoped Bean からのアクセス) はより単純に見え、同様に機能するはずです。

最後に、キャッシュを使用する場合は、古いキャッシュを回避する方法を検討してください。セッションごとにキャッシュすると、あるセッションでの変更は別のセッションでは表示されません。ちなみに、キャッシュを永続層に任せるもう一つの理由はこれだと思います。

于 2013-05-11T15:57:50.640 に答える