Ayende @ Rahien

Paul Stovell commented on A case study of bad API design: ASP.Net MVC Routing

Fri, 07 Nov 2008 03:07:08 GMT

Dang HTML... Should have read "Func(Of String, String)" and "Func(Of String, Bool)", but in C#.

Paul Stovell commented on A case study of bad API design: ASP.Net MVC Routing

Fri, 07 Nov 2008 03:05:12 GMT

I would have done: routes.Add("Default", "{controller}/{action}/id") .WithDefaults(controller => "Home", action => "View") .WithConstraints( controller => controller != "Secret", action => Regex.Match(action, "del*"), id => id >= 0); WithDefaults would be declared as taking a params array of Func . WithConstraints would take a params array of Func . The funcs would be auto-wrapped into an IConstraint or whatever. Intellisense would say: this takes a list of lambda's that accept a string and return a bool. The only implied part is that the "key" of the lambda must match the parameter name.

Steve Wagner commented on A case study of bad API design: ASP.Net MVC Routing

Thu, 06 Nov 2008 15:02:53 GMT

I think this is only a problem of documentation. If these method are get an nice in line help which show you how to use it, its all not so hard as well.

Torkel commented on A case study of bad API design: ASP.Net MVC Routing

Thu, 06 Nov 2008 07:43:48 GMT

I also found problems in the routing API, I created a custom fluent interface by overloading the Route class: [www.codinginstinct.com/.../...luent-interface.html](http://www.codinginstinct.com/2008/09/url-routing-fluent-interface.html) [www.codinginstinct.com/.../...e-in-mvccontrib.html](http://www.codinginstinct.com/2008/09/url-routing-available-in-mvccontrib.html)

Haacked commented on A case study of bad API design: ASP.Net MVC Routing

Thu, 06 Nov 2008 03:39:22 GMT

This is just one of those areas we made a trade-off in favor of usability over discoverability. [rickosborne.org/.../usability-vs-discoverability/](http://rickosborne.org/blog/index.php/2007/04/19/usability-vs-discoverability/) [www.scottberkun.com/.../26-the-myth-of-discover...](http://www.scottberkun.com/essays/26-the-myth-of-discoverability/)

configurator commented on A case study of bad API design: ASP.Net MVC Routing

Thu, 06 Nov 2008 02:00:30 GMT

While I agree that this is a terrible syntax, google is quite helpful in this case. It showed me how to send a regex, how to make a custom constraint, and even how to use HttpMethodConstraint to put a constraint on the HttpMethod (post or get). And all this just because I read this blog post and googled "mvc routing constraints"...

Jeff Handley commented on A case study of bad API design: ASP.Net MVC Routing

Thu, 06 Nov 2008 01:24:50 GMT

This was part of my problem with the HtmlHelper too. The (over)use of anonymous types can lead to usability problems.

Ayende Rahien commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 23:50:36 GMT

Andrew, There are different expectations for different platforms and languages.

Neil Mosafi commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 23:19:16 GMT

I'm sure a simple ///

comment would have helped here, but I generally hate seeing these kinds of APIs in C# - it s powerful enough that you can constrain people with static types. So much for intention revealing code.

Andrew Peters commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 22:46:15 GMT

Just a little bit of Rails love creeping into MVC. The key difference? With Rails I expect to have to use the docs and, luckily, they are great: [api.rubyonrails.org/.../UrlHelper.html#M001190](http://api.rubyonrails.org/classes/ActionView/Helpers/UrlHelper.html#M001190)

Stephen commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 22:30:52 GMT

Yea its one part of the mvc I've come to hate, its all started on a cute little concept of being able to generate dictionarys from anon objects.. a fluent interface sat on top of standard set of classes would have more code but a lot more understandable.

Josh N commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 22:04:05 GMT

Ayende, Another example of ASP.NET MVC making the case that dynamic languages are a better general purpose language.

Andrey Shchekin commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 21:24:45 GMT

I saw this some time ago, and this is ****the place that makes me careful about 'dynamic' support. And all what is needed to fix this a method to cast an anonymous type to an interface, like this routes.MapRoute(..., ..., new { Controller="...", Action="..." }.Cast

Demis commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 21:11:08 GMT

Its still in Beta, and overall I think its very well architected.

Haacked commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 20:48:56 GMT

Also, you can pass in a value as a string, in which case it's a regex, or a value that implement IRouteConstraint for custom constraints. For example: new {id="\d+", method=new HttpMethodConstraint("GET"), action="foo.*"}

Ayende Rahien commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 20:46:23 GMT

Phil, There is no difference between an API that takes a dictionary of untyped values and anonymous types

Haacked commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 20:46:15 GMT

Whoops, the MapRoute extension methods don't have overloads that take in a proper RouteValueDictionary. My bad. I meant, you can use routes.Add(...) which is much more explicit. The MapRoute extensions are a facade for those who like that approach using anonymous objects as dictionaries.

Haacked commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 20:43:38 GMT

Then use one of the other overloads take in a RouteValueDictionary. They are very discoverable. The object overloads was a trade-off we made in that we like the object initializer syntax for its terseness. Sure, it's not discoverable, but the other overloads are discoverable. I forget who said it, but one rule of usable design I've heard is that if you can't make it discoverable, at least make it memorable. The idea being that now that you know this is the pattern for routes, you'll never forget it.

Jeremy D. Miller commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 19:57:05 GMT

I think it's one of those cases where you really need to write your own API wrapper around routing to make it more discoverable. It's a very MS-ish API.

Ayende Rahien commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 19:50:40 GMT

Ben, There is absolutely no way I would figure out this thing out. Even from reading the code, I found out that I needed to implement the interface. Yuck even more.

Ben Scheirman commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 19:46:50 GMT

Yeah, that isn't at all discoverable. Since your route values are just arbitrary name/value pairs, it accepts an anonymous dictionary for the constraints, which are typically regex. something like this: routes.MapRoute("foo", "blog/archive/{year}/{month}/{day}", new {controller="blog", action="postsByDate"}, new {year=@"\d[4]", month=@"\d2", day=@"\d2"} public class BlogController : Controller { public ActionResult PostsByDate(int year, int? month, int? day) { ........ } } I agree that this syntax is not at all discoverable, but once you know it.... (I'd much prefer a fluent interface over this).

João Bragança commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 19:45:32 GMT

I thought anonymous types couldn't implement interfaces. So why doesn't the method only accept IRouteConstraint?

josh commented on A case study of bad API design: ASP.Net MVC Routing

Wed, 05 Nov 2008 19:38:38 GMT

ouch. I think a person from the MVC team is a reader of yours (not naming names), and is pretty open and responsive. perhaps something can be done.