3

context.Server.MapPathapp_dataフォルダーの下にある既知のディレクトリ/ファイルの物理的な場所を特定するためだけに毎回使用するのは奇妙だと思います。アプリケーションが実行されると、最初にシャットダウンせずに物理的な場所を変更することはできないはずだと私は理解しています。これが当てはまる場合は、app_startにapp_dataの物理パスをキャッシュし、そのキャッシュ値を実行期間中使用できます。

この件について専門家の意見が必要です。私の仮定は正しいですか？アプリケーションを再起動せずにアプリケーションの物理パスを変更する可能性はありませんよね？

これが本当なら、すべての奇妙なメソッドにパラメーターとしてコンテキストを含める必要がなくなるので、時間を大幅に節約できます。

メソッドインターフェイスの明確さは私にとって最も重要であり、<context>はそれに適合しません。

ところで、私は共有ホスティングを使用しているので、アプリケーションの物理的な配置を制御できません。これは重要ですか？

4

3 に答える 3

1

パスは現在のリクエストからの相対パスであるためMapPath("foo")、異なるURLのリクエストでは異なる結果になる可能性があります。ただし、パスがapp-root（"~/foo"）またはsite-root（"/foo"）に相対的である場合は、心ゆくまでキャッシュすることができます。

実行中にIIS内に仮想ディレクトリを追加するというエッジケースのシナリオがあるかもしれませんが、それはほとんどあり得ず、とにかく痛みを引き起こす可能性が非常に高いです。

于 2011-05-31T18:04:28.823 に答える
0

コンテキストをパラメータとして渡す必要はないと思います。使用する可能性は常にあります

 HttpContext.Current.Server.MapPath("~/...");

これは、変数をキャッシュに保存するよりも簡単です。

編集：このような呼び出しにコストがかかると本当に思われる場合は、ルートパスを格納できるプロパティを使用してシングルトンクラスのアプリケーションを作成します（例：次のように）。

public class Application
{
  private static string _rootPath = HttpContext.Current.Server.MapPath("~");
  public static string RootPath
  {
      get { return _rootPath; }
  }
}

どこからでもルートにアクセスできます。このコードはglobal.asaxにも入れることができます。

于 2011-05-31T18:12:19.417 に答える
0

私があなたなら、何もキャッシュしません。キャッシュによって何かが速くなるとは思わないからです。またはそれが速かった場合、それは約数ナノ秒でした。

コンテキストを渡すという問題については、これは設計によるものです。

コードをリファクタリングして、IO操作を実行する単一のポイント（IOHelperクラス）を作成し、そこにコンテキストをキャッシュします。

于 2011-05-31T18:39:21.910 に答える