システム開発で思うところ

JavaEEを主にシステム開発をしながら思うところをツラツラを綴る

スコープについて

@ConversationScoped

画面操作に関するスコープ

実装イメージ

  • 開始ポイントを必ずindex.xhtmlにする。
  • ファイル名を除くフォルダパスが変更されるタイミングを@ConversationScopedの開始・終了の境界にする。
  • index.xhtmlは省略可能にする。(SAStruts風?)。
  • 同一会話内の画面遷移はxhtml名だけで遷移する。.xhtmlの省略不可。
  • 会話開始前にindex.xhtml以外のパスにアクセスをしようとしたら、同一フォルダのindex.xhtmlフォワードする。
  • 画面遷移はリダイレクトするようにInterseptor?faces-redirect=true";を付与する。同一画面遷移(return null)の場合は、自画面パスを取得して対応する
  • サブフォルダも親フォルダの会話範囲にする*1

考察

@ViewScopedJSF依存)は使わない

  • フォルダパスが変わらない=同一画面ということになるので、会話の開始・終了のタイミングは問題なさそう。
  • クライアントに情報を持たないので通信量が少なくて良さそう。

@FlowScopedJSF依存)は使わない

  • 同一会話を同一フォルダまたは子フォルダで表現すれば求めている要件は満たしている。
  • @FlowScopedと違って遷移フローのためのクラスとかXMLを作成しなくていいので分かりやすくなりそう。
  • jarにして部品化することは出来なくなる可能性大?。部品化する場合、仕組みを含めて全て取り込まないといけないことになるのでサイズが大きくなってしまう?。

@RequestScoped

単純な参照のみの画面の事を考えて@RequestScopedは残す。

実装イメージ(悩み中)

StatelessViewの強制

Stateless Viewの制御を@RequestScopedを使用した場合に強制的に行うようにInterseptorで対応。

閲覧のみのコントローラーですよ、ということが分かるようにする工夫が必要かな。

@ApplicationScoped

ビジネスロジック

パーフェクトJavaEEを見ていると、Serviceなどのビジネスロジックは、このスコープにしておくと良さそう。ビジネスロジックに状態を持ってはいけないという思想としても正しいと思う。

インフラレイヤー

コネクションとかインフラ関係でコンテナに1つあれば十分のインスタンス

ユーティリティクラス(悩み中)

ユーティリティクラスをInject対象にする状態が、すでに良くない気がしている。でもテスト容易性のためにstaticクラスにしないで、ということはあるかもしれないので、一応想定はしておく。

@SessionScoped

ユーザー情報

  • ログイン以降のユーザーの状態。
  • 認証・認可

ゲストユーザー情報

  • ログインする前の状態保持。ショッピングカート的な仕組みだと必要かも。

*1:2017/8/6 追記:スコープが広すぎるので対象外にするべき?