内联路由应该在全局路由之前还是之后检查？
我正在编写一个 Web 框架，一个巧妙的功能（IMO）是您可以定义内联函数的网址，如下所示：
[Url(@"/profile:(?<username>\w+)")]
public void Profile(string username)
然后当您访问 /profile:someusername< 时，该函数将自动被调用/code> 和 someusername 将被传递到函数中并自动进行类型转换。
但对于那些喜欢旧的处理方式的人来说，您仍然可以在一个地方指定所有路由：
List<Route> Routes = new List<Route> {
new Route(@"/user:(?<id>\d+)", "UserController.View")
};
现在我只是想决定应该以什么顺序处理这两种不同的方法。
哦，把全局路由放在第一位意味着您可以在内联路由抢夺它们之前预先处理所有特殊情况，但是OTOH，如果您将全局路由放在前面，则无法将所有后备路由放在那里。所以我不能完全决定哪个顺序更好......
我猜的另一个解决方案是使用优先级队列，用户可以为某些路由提供更高或更低的优先级。
I'm writing a web framework, and one neat feature (IMO) is that you can define the web address for a function inline, like so:
[Url(@"/profile:(?<username>\w+)")]
public void Profile(string username)
And then that function will automatically get called when you visit /profile:someusername and someusername will get passed into the function and get type-casted automatically.
But for those that like the old way of doing things, you can still specify all the routes in one place:
List<Route> Routes = new List<Route> {
new Route(@"/user:(?<id>\d+)", "UserController.View")
};
Now I'm just trying to decide what order the two different methods should be handled in.
OOH, putting the global routes first means you could handle all the special cases upfront before the inline routes snatch em up, but OTOH, if you put the global ones up front you can't put all the fall-back routes there. So I can't quite decide which order is better...
The other solution I guess is to use a priority queue and users can give higher or lower precedence to certain routes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我看来，更具体的路线应该优先于一般路线，因为它们指定了更具体的行为。
顺便说一句，我喜欢这个功能，因为它从全局定义中删除了特定的路由，并且不会使其混乱，因此您可以更好地概览，并且您无需在方法中指定它们，而是在实际使用它们的位置中指定它们，这有助于可读性。
In my opinion, more specific routes should be predecent to general routes, simply because they specify a more specific behaviour.
I like this feature btw, as it removes the specific routes from the global definition and doesn't clutter it, so you have a much better overview, and you don't specify them in methods but actually where they are used, which helps readability.