I'm guessing you're being downvoted because you're calling people retards because of what you perceive to be a poor design, when in reality they've done exactly what you've said, you just don't realise it. Which makes your "incompetent idiots" remark rather ironic and gave me a good chuckle. For the competent, or consciously incompetent:

1. ASP.NET MVC implements customizable routing, like pretty much every other modern web MVC framework these days. The routing library can actually be used in old school ASP.NET Web Forms applications or your own raw ASP.NET application, if you like; it is not ASP.NET MVC specific.

2. The default route in the code generated as part of the "ASP.NET MVC Web Application" template project in Visual Studio maps routes as follows: /{controller}/{action method}/{id parameter}. There's nothing stopping you from (a) changing this in the generated source code (Global.asax.cs) or (b) generating an EMPTY default web application without the code at all and zero routes pre-defined.

I found the magic just got in my way when I first got into ASP.NET MVC. I needed to use Firebird with Entity Framework but I didn't want to use that horrible feature which connects to the database and maps it automatically for you using a GUI. Mapping my model to the database is just something I'd rather do manually, and eventually I figured out how to do it and it's awesome.

I don't use membership so it doesn't infect my db.

YES. THANK YOU.

Sorry, wait - how is this different than the RoR magic. Where you can do stuff like MyObject.findByArbitraryProperty and it just works? That's PFM if you ask me. Django, RoR, and Node all have lots of magic bits. You don't have to use any of the magic, which also goes for MVC.

(I do agree with you though - just because other frameworks have magic bits doesn't mean I like it in MVC. I would also prefer it not be there. I just don't think you can really pick on MS in this case.)

It doesn't fit the language and the environment.

ASP.NET MVC is way too much of a RoR clone than is good for them. C# programmers aren't used to magic: they're used to compilers telling them about typos. Convention over configuration is nice, but it's essentially the concept of dynamic typing translated to frameworks. It fits badly in a statically typed language.

I'd have much preferred ASP.NET MVC to have less magic and, for instance, decent, controllable, IDE-supported and compiler-guarded routing.

Example: in an action method, parameter names are mapped to URL parameters. This is horrible, I should be able to change the parameter name in any method without calling code being affected. Or, when this is not the case (e.g. when C# 4's named arguments feature is used in calling code), I want a compiler error saying that calling code can't find the parameter anymore.

In ASP.NET MVC, I get neither of those things. I might have as well gone Ruby all the way, then.

In short, it's brittle.

Compiled languages have pros and cons, but if you're compiling anyway, please use all the pros to the max. APS.NET MVC doesn't, and that's a shame.

It's still a nice enough framework, but it screams "missed opportunity", much like all those Java libraries that were ported over to C# back when .NET was new.

Binding between a request and a controller method is entirely customisable. The framework uses a completely customisable number of parameter sources (query string parameters, POST parameters, session variables, you can customise this to e.g. query LDAP if you want) and binds those to the parameters of your method in a completely customisable way. See, for example http://odetocode.com/blogs/scott/archive/2009/04/27/6-tips-f... .

That being said there is definitely a deficiency in strong typing in ASP.NET MVC as-is. That's why I use T4MVC (http://mvccontrib.codeplex.com/wikipage?title=T4MVC_doc&...). I'm not too sure how the MVC team have done things much differently, though, without overcomplicating the framework... you'll note the T4MVC approach is based on code generation that inspects your source tree.

Wow, cool stuff!

I think code generation from inspecting source trees really is the future for compiled languages.

I used to think that the only reason to generate code (instead of using reflection or interpreting some DSL) was speed. I missed how code generation gives you excellent additional features, such as more compile-time safety and, most importantly, excellent IDE support. Once my code is generated, I can talk to it from other code like it was a hand-written library including all the IDE goodness (API discovery through autocompletion, etc) that it comes with.

I really hope they'll keep making T4 even more awesome than it already is. Combined with Roslyn, I think we'll get some pretty cool tools ahead that we can't even fathom now.

.NET magic is generally limiting things down so that happy path works and edge cases are expensive. Other platforms do a much better job of this because they start on an edge and make that run through happy path by convention. I can't speak to it being language limitations or just the way Microsoft works, but they almost always seem to get this part wrong.

See ASP.NET MVC Routing as a example (kinda related to the above).