ASP MVC 5有一个名为属性路由的新路由。我看到它的方式，路径现在分散在每个控制器上，不像基于约定的单一位置RouteConfig.cs，您可以在其中检查您的路线，这也可以作为您的站点路线的文档以某种方式。
我的问题是，在可读性和可维护性方面，使用基于约定的路由的属性路由更好吗？并且有人可以建议如何设计路线以获得更好的可维护性和可读性。
答案 0 :(得分：21)
为了解决您的第一个问题，散布路线有许多优点：
它将路由信息放在与实现该路由的控制器操作相邻的位置。这有助于调试和故障排除，并提供快速搜索解决方案中的路径信息的能力。
降低了路线变更过程中的风险。在RouteConfig.cs或WebApiConfig.cs中（在Web API解决方案的情况下），存在无意中更改错误路由或以其他方式对应用程序的其他部分产生负面影响的可能性。
您可能还希望包含可接受的HTTP方法，允许的用户类型和注册优先级，如果包含在基于属性的路由中，则将所有这些信息放在一起。
这篇文章为我提供了上述灵感和强化，并详细介绍：http://kevinmontrose.com/2011/07/25/why-i-love-attribute-based-routing/
答案 1 :(得分：1)
使用传统路由时，您可以对您的路线进行单元测试，并且您也有“分离关注点”。
关于属性路由的说法不行。
对于一个大项目，我会选择传统的，对于一个小项目属性路由非常好。
答案 2 :(得分：0)
属性路由为您提供了更多便于路由选择的广告选项。
请查看以下内容：Routing explanations
答案 3 :(得分：0)
我认为从可维护性和可读性的角度来看，如果你有一个适合基于约定的路由的项目，那么就去做吧。在配置文件中包含一些路由比装饰每个控制器要简单得多。
但......
根据我的经验，基于约定的路由过于简单化，并且经常会分解大型或更复杂的项目。经常发生的是您从默认的{controller} / {action} / {id}路线开始。但是你决定需要更多的路线，因为你需要更深层次的层次，所以开始添加路线。这样的事情：/ company / 5 / employee / 7 / edit。然后你必须要小心你的路线的顺序，以便找到正确的路线。一旦开始添加自定义路由，您可能会发现更多的路由与特定请求匹配，因此您添加了一些路由约束。随着您的项目变得越来越大和/或越来越复杂，您的路由配置的大小和复杂性也越来越大，这使得它容易出错且难以维护。
属性路由使您可以更好地控制路由，因为您可以将特定控制器和操作映射到特定路由，而不必担心错误的路由将匹配。此外，由于路线非常靠近控制器故障排除路线更容易。
TL; DR：无论您使用基于约定的路由还是属性路由，在某个时刻路由变得更加难以维护。属性路由就是控制路由并避免路由错误。
另一个看起来很有希望的替代方案是MvcCodeRouting，它是基于命名空间的路由