0

Weld で JSF、Hibernate、CDI を使用しています。私のアプリケーションは、ビュー (xhtml)、コントロール (リクエスト/セッション/ビュー スコープ Bean)、モデル (エンティティ)、およびビジネス (アプリケーション スコープ Bean としてマークされた BO) に分かれています。

モデルとビジネス レイヤーをビューとコントロールからできるだけ切り離すようにしています。つまり、すべての xhtmls + コントロール Bean を変更したい場合、ビジネス レイヤーとエンティティに影響を与えることなく可能です。

私の問題は次のとおりです。ビジネス層には、ログインしたユーザー (または少なくともそのプロファイル) を知る必要があるメソッドが多数あります。これは、制御層に返される結果に影響を与えるためです。

例: 編集するユーザーのリストを要求すると、管理者はすべての登録済みユーザーのリストを受け取り、管理者は自分のプロファイルの「下」にあるユーザーのみのリストを受け取ります。

セッション Bean (ログインしたユーザーを含む) をビジネス レイヤーに挿入したくありません。これは、カップリングが発生するためです (つまり、コントロール/ビュー レイヤーをいつでも変更することはできません)。

現在、ログに記録されたユーザーを BO のメソッドのパラメーターとして渡すことでこれを行っていますが、私にはそれが「間違っている」と感じています。コントロール層は、ログインしたユーザーとして必要な人を渡すことができ、ビジネス層はそれを決して知らないと考え続けています。

私の最後の質問は次のとおりです。

  1. 私のやり方に何か問題がありますか？それとも私が考えすぎですか？
  2. それを行うより良い方法はありますか？
4

1 に答える 1

0

ドメイン層の Bean が取得できる場所から、ユーザー ID をセッション スコープに配置しても問題ないと思います。ドメイン層がユーザー ID について知る必要がある場合、それはドメインの概念であり、そこにオブジェクトが存在してもかまいません。

ただし、プレゼンテーション レイヤーから抽象化が漏れることを懸念しているのは当然です。ドメイン層でユーザー ID のインターフェイスを定義し、ドメイン層のコードをそのインターフェイスに関して記述し、プレゼンテーション層からその実装を挿入することをお勧めします。インターフェイスはドメイン層で定義されるため、ドメイン コンセプトの観点から記述することができ、プレゼンテーション コンセプトの漏洩を防ぐことができます。

プレゼンテーション レイヤーを変更したい場合は、インターフェイスの新しい実装を作成する必要がありますが、それは問題にはなりません。

別の方法として、Java Authentication and Authorization Serviceを使用して、ユーザー ID がドメイン層に渡される実行スレッドにバインドする方法があります。そのレイヤー内のオブジェクトは、標準の JAAS 構造を使用してアクセスできます。コンテナが JACC をサポートしている場合、すでに JAAS を介してユーザー ID を使用できるようになっている可能性があります。よくわかりません。

于 2012-07-19T21:01:46.363 に答える