2012-02-14 75 views
0

我一直負責爲客戶端創建麪包屑功能。他們目前的網站設置爲基於XML /文件。每個.aspx頁面都是N層深,並且有一個控件連接到相應的.xml文件。IIS7重寫模塊和ASP.net Request.PhysicalPath

我決定通過pages目錄結構實現麪包屑。我抓取物理路徑,剝離根目錄,分割目錄,並使用這些部分作爲我的麪包屑。他們的所有文件夾都在CamelCase中命名,所以我使用駱駝套來打破這個詞來顯示。

如:網站可能看起來像

首頁

- 子目錄1

------子目錄1.1

----------我的頁面的.aspx

- 子目錄2

------ MySecondPage.aspx

如果您對「MyPage.aspx」 ..你得到的麪包屑是:

首頁 - >子方向1 - >子迪爾1.1 - >我的網頁

這裏是我有問題。客戶端也使用IIS7重寫模塊強制使用小寫URL。問題在於,我在Request.PhysicalPath調用中返回的值全部是小寫,所以我的顯示文本不起作用(因爲它依賴於CamelCase)。如果我關閉IIS7執行,它將如上所示顯示。如果沒有,我會得到:

首頁 - >子目錄1 - >子目錄1.1 - >我的空間

反正是有強制通過IIS7重寫模塊小寫的網址,而不會影響Request.PhysicalPath (或Request.PhysicalApplicationPath)調用?

謝謝

回答

0

我覺得在這種情況下你不能依賴Request.PhysicalPath。

嘗試使用approach from this question獲取實際文件名的正確外殼

+0

完美。到底我在找什麼,你最好。作爲一個後續問題,因爲這個實現將被用於構建麪包屑並因此以頁爲單位進行調用,所以您認爲每個循環訪問I/O至少幾次會產生什麼樣的影響,請遍歷至少循環幾次(對於n深度目錄級別n次),每頁加載? – MikeAtCodeSmart 2012-02-15 17:03:17

+0

是否值得添加緩存機制來緩存格式化的路徑信息並使用該值而不是每次都去文件系統? – MikeAtCodeSmart 2012-02-15 17:04:20

+0

沒有測試就很難預測性能。但是,在類似的情況下(當結果不會隨時間變化時),我通常使用靜態ConcurrentDictionary或HttpApplicationState來存儲結果,這很容易實現,並保證沒有還原劑I/O。 – Artem 2012-02-15 19:31:38