サービス層はHttpContextにアクセスする必要がありますか？

Question

私は、ConeryのMVC Storefrontの初期バージョンと同様に、サービスレイヤーが上にあるリポジトリパターンにほぼ沿ったアプリケーションを構築しています。

現在のユーザー以外のすべてのユーザーを返すページを実装する必要があります。私はすでにリポジトリとサービスレイヤにGetUsers（）メソッドを持っているので、 "現在のユーザーを除いて"を適用する場所が問題です。

サービス層はHttpContextを認識するべきなので、このルールを適用しますか？現在のユーザ（ID）をコントローラからこのサービスメソッドに渡すだけですが、サービスレイヤがHttpContext対応であり、これを独自に行うことができれば、より清潔に見えます。

1つの明白な選択肢はコントローラ内で直接このルールを適用することですが、私はその考えにだけ熱くないんだけど...

---

編集 - ちょうど回答にコメントする：私は問題を参照してください逆依存関係の問題で、私は完全に見落とされていました。私は投票の答案としてMehrdad'sをマークしていますが、誰もが実際に読む価値のある貴重な回答を提供しています！

Answer 1

絶対にありません。私は、Webアプリケーションと一緒にWindowsベースのアプリケーションを作成し、Web固有のものへの依存を最小限に抑える必要があると想定しています。 HttpContextを直接渡すと、Web UIレイヤーへのサービスレイヤの結合が向上しますが、これは理想的ではありません。

Answer 2

サービス層とWeb層の間に逆の依存関係を作成する必要があります。フォームベースのアプリケーションまたはWindowsサービスで動作するようにサービスレイヤーを拡張する場合、何が起こるかを検討してください。今では、Web依存関係を回避して、同じメソッドをいくつか（おそらくは、小さいが重複している）コードを作業または複製するようにする必要があります。ユーザーの識別子をサービスレイヤのコンテキストで有用なものに抽出し、その値をサービスレイヤで使用する方が良いでしょう。 Webサイトでのフィルタリングの処理も許容されますが、何度もやり直す場合は、共通の場所にリファクタリングする必要があり、サービスレイヤーは自然な場所です。

Answer 3

現在のユーザーオブジェクト（およびその他のコンテキストデータ）を含むカスタムAppContextクラスを作成することをお勧めします。このクラスにはSystem.Webへの参照はありません。コンテキストを認識する必要のあるサービスメソッドには、AppContextパラメータ（たとえば、セキュリティ権限の確認や現在のユーザーの取得など）が必要です。このオブジェクトをWeb層に配置し、必要に応じてセッション内に保持します。このようにして、サービス層はSystem.Webについて何も知りません。

Answer 4

答えは、なしです。

サービス層は現在のプレゼンテーション層に依存していないだけでなく、私の意見では現在のアプリケーションに依存しないはずです。たとえば、カスタムAppContextクラスをJonoWとして提案すると、hereと表示されません。

代わりに、GetAllUsersExceptForTheCurrentUserメソッドのパラメータとして現在のユーザーを渡します。この方法では、現在のアプリケーションだけでなく、ユーザーを処理する必要のあるアプリケーションでサービスを使用できます。

Answer 5

いいえこれを行うと、コードをテストして再利用することが難しくなります。

私はこの種のもののためのインフラインターフェイスを構築（IAuthenticationか何かそれを呼び出す）と、その上にあるCurrentUserプロパティを公開する傾向があります。それから私はコンストラクタを介してこれを私のサービスに注入します。すなわち、公衆たMyService（IAuthentication払い）

最後に、あなたはIAuthentication（WebAuthenticationを言う）のHttpContextを認識して実装を構築することができますと思います。あなたがあなたのサービスを作成するときに

は今、あなたにもその依存関係を作成します。

var myService = new MyService(new WebAuthentication()); 
var otherUsers = myService.GetAllOtherUsers(); 

あなたはIoCコンテナを使用している場合は醜い依存関係はさらに離れて行くことができます！