0

フレームワーク: ASP.Net MVC 3

リクエストが届くと、グローバル フィルターを介してリクエストをインターセプトし、サブドメインに基づいてデータベース ルックアップを実行します。DB ルックアップからの戻り int は、そのデータが必要になるたびに DB ヒットを再度実行する必要がないように、他のオブジェクト (つまり、コントローラー) に永続化する必要があります。

この情報はシステムの重要な部分であり、有効になっている Cookie に依存したくないため、Cookie の使用を避けたいと考えていました。

関連する質問hereおよびhereを読みましたが、適切な回答が得られませんでした。

私は実際に2つの質問があります：

  1. 今のところ、私は面倒な作業を行うサブドメインマネージャーオブジェクトを思いつきました.IoCを介してマネージャーオブジェクトをHTTPリクエストスコープに設定し、可能な解決策としてリクエスト中にいつでもそのマネージャーを取得できます.

    この情報を調べた後、MVC リクエスト パイプライン内の別のオブジェクト間でこの情報を運ぶより良い方法はありますか? - 何らかの方法で情報をリクエストに戻すというアイデアを検討しました (これは質問 2 に関連します)。

  2. リクエストを使用してデータを保存する場合 (つまり、リクエストをインターセプトし、ルックアップを実行し、リクエストに書き込む場合)、その情報を保持する論理的な場所はどこでしょうか?

    セッションを確認しましたが、これは Web サーバーがセッション用に構成されている方法と密接に関係しているようで、既に Cookie を使用したくないと述べました。投稿データやクエリ文字列コレクションなどのその他の領域は、セキュリティ上の理由からロックダウンされています。

助言がありますか？

4

2 に答える 2

2

IoC コンテナと http リクエスト スコープを使用した最初のアプローチはうまくいくと思います。

2 番目の質問: 適切な場所はHttpContext.Items、現在の要求の有効期間にわたってキーと値のペアを格納するストアです。

于 2012-06-01T12:01:01.873 に答える
1

1かなり近いです。

サブドメインマネージャーはおそらくシングルトン（おそらくIOCコンテナーを使用）であり、データが最初にロードされた後にサブドメインを検索するための単純な静的ディクショナリを備えている可能性があります。この初期ロードが発生し、データロードを複数回実行せずに複数のサーバー間で同期されることが懸念される場合は、DB呼び出しを行うオーバーヘッドに応じて、分散キャッシュ（appfabric、ncache、memcache）を確認できます。

ただし、IDを格納するためにHttpContext.Itemは使用しません。IOCコンテナを使用して、これをコントローラーに注入します（おそらくプロパティ注入）。ほとんどのIOCコンテナを使用すると、HttpRequestの開始時にこの起動が発生し、「ユーザーセッション/トランザクション」の存続期間中続く可能性があります。

NHibernate Burrowsを使用すると、これらすべてを簡単に実装でき、笑えるhttp://nhforge.org/wikis/burrow/default.aspx

于 2012-06-01T12:07:30.257 に答える