2011-10-06 76 views
2

我一直受益於網站地圖的優勢,爲現在而:是否可以從ASP.NET路由中推斷網站地圖?

  • 外在頁的關係。頁面不負責定義他們自己的關係,而是由外部提供者提供。當涉及到渲染導航控件時,這消除了頁面上的大量責任。例如。 「渲染我的孩子」而不是「我是產品列表頁面,所以我應該呈現產品列表」。
  • 頁面關係可以從任何地方推斷。例如。站點地圖頁面變得完全自動化,麪包屑和頂層導航也一樣。
  • 通用導航。可重複使用的控件可用於呈現任何類型頁面的鏈接列表。

到目前爲止,我還使用SiteMapProviders作爲路由機制。我一直在分別在每個節點的Url和Key屬性中存儲一個「路由URL」和一個「處理程序URL」。即一個請求進入,FindSiteMapNode方法被調用,並且請求被重寫爲返回的節點的密鑰。

這工作完美,但我知道時代正在改變,我們現在有路由表。

經過一番研究,似乎不能從路線中推斷出頁面之間的關係。 Ergo:「無法從路由表中推斷站點地圖」。 (我是對吧?)

假設這個聲明,我該如何保持我的精彩站點地圖與時俱進?在兩者之間沒有大量的代碼重複嗎?根據我目前的方法,我將從路由表中獲得哪些具體收益?

我已經看過:ASP.NET URL Routing with WebForms - Using the SiteMap,它指向http://chriscavanagh.wordpress.com/2009/05/19/asp-net-webform-routing-with-sitemaps/

然而,溶液僅允許節點和路由之間的映射1..1分別。例如,使用此方法不能讓許多產品節點指向單個路由。

回答

3

「這很好,但我知道時代正在改變,我們現在有 有路由表。」

爲什麼要改變一些完美的東西給你?我建議你根據你提供的信息不做任何改變。我明白希望和願望使用新的閃亮的東西,但是,你有一些工作,並符合你目前的需求。

+0

我自己在想這個。不過,我一直採用這種功能的理念是有充分理由開發的,從我看到的現在它成爲路由URL的標準方式。如果微軟這次投資開發它,而其他人都在這樣做,那麼我是不是錯過了什麼? –

+0

不,不是真的,我在使用「MasterPages」之前就已經存在了,但是發佈後我沒有重寫我的應用程序。新應用程序是。在Microsoft解決它們之前存在問題,它們的解決方案並不總是最適合您的應用程序。您的架構基於您需要的可能與其他新技術/方法不一致,因此無需將其強制爲新約束。 –

相關問題