質問

2つのプロジェクトがあります。すべてのロジックとデータアクセスを含むDLLプロジェクトと、フォームなどを行うASP.NETプロジェクトです。

少し混乱しています。 System.Web名前空間参照をDLLプロジェクトに追加すると、ASP.NETページのセッション状態情報を参照できると考えました。

各ページを使用してセッション情報を取得し、処理のためにDLLに渡すことができますが、DLLクラスから直接処理できるようになりたいです。

これは可能ですか?

System.Web名前空間をいじってみましたが、セッション変数への参照を取得できるようです。

ありがとうございます。

ジョン

役に立ちましたか?

解決

HttpContext.Current.Sessionを使用できるはずです

編集

はい、私はあなたのビジネスロジックDALまたはその他のアセンブリをASP.Netセッションに緊密に結合すべきではないことに同意します。 Webプロジェクトの外部でHTTPコンテキストにアクセスするための有効なケースはたくさんあります。

Web Controlsは、おそらく最高の例の1つであり、再利用可能なhttpモジュールなどです...

DLLにSessionからデータをプルさせる場合の1つのオプションは、セッションを抽象化することです。そのため、ライブラリが使用方法を認識できるように、IStorageのようなインターフェイスを定義できます。次に、SessionStorageまたはMemoryStorageクラスを作成し、IoCを使用して適切なクラスをライブラリクラスに注入します。これにより、コードをSessionに結び付けることなく、コードを自由にコーディングできます。ああ、もう1つの利点は、適切に行われれば、コードをWebのセッションにも結び付けないようにするために使用できます。

他のヒント

アセンブリがセッションのスコープに読み込まれている限り、アセンブリにアクセスできます。

このタイプの密結合はあまりお勧めできませんが。

常にHttpContext.Current.SessionをDLLで使用できますが、これは悪い習慣と見なされます。より良い方法は、セッションを参照する代わりに、セッション辞書に保存されている値をDLLに渡すことです。もう1つの利点は、DLLのコードがASP.NETランタイムに結合されないことです。つまり、テストが容易になります。

他の人が言ったように、あなたはいつでもあなたのDLLでHttpContext.Current.Sessionを使うことができます、私はそれがあなたのBALであると仮定しますが、本当に注意する必要があります。 DLLが後でWindowsサービス、またはHTTPContextを持たない他のアプリによって消費された場合はどうなりますか?これを行うたびに、プロパティ取得メソッドに常にあり、try catchブロックでHttpContext.Current.Sessionへのアクセス試行をラップし、何か問題が発生した場合は、dbから必要なデータをリプルします。

HttpContext.Current.Sessionを使用しないでください。dllがWebアプリケーションで常に実行されるわけではありません。 Windows、Console itcなどの他のアプリケーションで実行できます。

ASP.Netアプリケーションを使用している場合は、セッション値から来るパラメーターを実際に受け入れるメソッドを使用することをお勧めします。そうしないと、アプリケーションの依存関係がなくなります。 dllプロジェクトが既に開発されていて、既存のビジネスロジックを変更しようとしている場合、いいえ、既存のメソッドを変更しないでください。オーバーロードメソッドを使用してください。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top