屬性與傳統路由

Question

Q1：因此article表示屬性路由比api版本控制的傳統路由更有利。目前尚不清楚，以我這樣的要求背後的原因，因爲對我來說，以支持這些：

/api/v1/products 
/api/v2/products 

所有你需要做的就是定義兩條路線：

routes.MapHttpRoute("V1", "api/v1/products", new {controller = "V1Controller", action = "ListProducts"}); 
routes.MapHttpRoute("V2", "api/v2/products", new {controller = "V2Controller", action = "ListProducts"}); 

能否東西分享一些見解？

Q2：this article表示傳統路由的一個問題是表中條目的順序，並且您可能會意外地將請求映射到錯誤的控制器。爲什麼這不是屬性路由的問題？我的意思是模板只是一個字符串，所以它如何防止我定義兩條路線，其中一條比另一條更通用？

問題3：你可以給一個混凝土的例子，你可以完成屬性路由，但不能用傳統的路由嗎？ - 我不是在談論代碼的可讀性和可維護性。

Answer 1

Q1

文檔特別指出「可以很容易」爲API版本，而不是「使得它更容易」或「優選」。

我不同意基於約定的路由必須「難以支持」（假設您瞭解路由的工作原理）。但是，如果您沒有使用在項目中的多個控制器間共享的約定，那麼使用屬性路由時維護的代碼要少得多。也就是說，您不必在代碼中指定每路由上使用的控制器和操作，因爲RouteAttribute知道它本身與其配對的操作/控制器。

但正如文件指出的那樣，將所有路線放在一個地方也是有好處的。如果您的API可以使用適用於多個/所有控制器的約定，那麼設置單個約定比多個路徑屬性更容易維護。

對於那些使用內置的MapRoute方法可能「難以支持」的約定，您可以使用自己的擴展方法擴展基於約定的路由，甚至可以繼承類來定義它們。

Q2

訂購是與屬性的路由問題。事實上，屬性路由使得查看你的路由註冊的順序變得更加困難。並不是所有的路由都是順序敏感的，因此它在很大程度上不是問題。

但是，當您的確實與屬性路由有順序問題時，它比使用基於約定的路由時要微妙得多。當反射檢索它們時，屬性do not guarantee any order。因此，無論您在控制器操作中指定它們的順序如何，默認順序都是未知的。

固定屬性路由排序可以很容易。只需指定屬性的Order屬性（在較高值之前評估較低值）。

這就是說，有no way to specify order between different controllers，所以它可能最終會咬你。如果發生這種情況，唯一的內置選擇是基於約定的路由。

Q3

我不能給的，你可以使用屬性的路由，你不能使用基於約定的路由的具體例子（據我所知，沒有一個）。以屬性路由不支持的方式使用基於約定的路由的一個示例是製作data-driven CMS routes。

屬性路由支持基於約定的路由支持的功能的子集。它在技術上並不比基於會議的路由更高級。基於會話的路由選擇使您能夠直接指定自己的RouteBase（或Route）子類，從而允許您執行許多無法使用內置屬性路由的事情，例如基於子域的make路由，查詢字符串值，表單後值或Cookie。您甚至可以在高級場景中製作擴展方法。

屬性路由無法通過反射進行擴展，因爲它使用的許多類型都標記爲內部。

但也有可能會考慮使用屬性，而不是路由以公約爲基礎的路由，這取決於你的項目3個令人信服的理由：

1. 它把路線的背景下，與控制器代碼的其餘部分，這可能會更容易維護。
2. 這意味着您不需要在每個路由定義中鍵入（或複製並粘貼）控制器和操作名稱。在維護性方面，在路由和控制器之間維護這種關係（並且解決它的錯誤）可能花費比在一個地方定義所有路由更值得的成本。
3. 屬性路由是比基於約定的路由更容易學習。如果您的期限很緊張和/或您的團隊對路由沒有經驗，那麼使用屬性路由可能是一個更好的選擇，因爲學習曲線更短。

需要從這件事中拿掉的東西是：使用最容易在項目中維護的路由類型。如果您有很多類似的模式，請使用基於約定的路由。如果您的URL在整個項目中不一致或不一致，或者您只是希望在工作時看到與您的操作方法相同的上下文中的URL，請考慮屬性路由，但請記住，基於約定的路由是另一種選擇。

注意：我鏈接到的大多數示例都是針對MVC而不是Web API的。這兩個框架之間的路由非常相似（實際上，大多數代碼類是共享的）。就屬性/基於約定的路由而言，可以在MVC和Web API中使用相同的概念，但是請注意，如果您使用的是Web API，並且您想要定位System.Web.Http名稱空間而不是System.Web.Mvc名稱空間利用這些例子。