Why does the .Net world seem to embrace magic strings instead of staticly typed alternatives?

Question

So, I work in .Net. I make open source projects in .Net. One of my biggest problems with it isn't necessariyl with .Net, but with the community and frameworks around it. It seems everywhere that magical naming schemes and strings is treated as the best way to do everything. Bold statement, but look at it:

ASP.Net MVC:

Hello world route:

        routes.MapRoute(
            "Default",                                              // Route name
            "{controller}/{action}/{id}",                           // URL with parameters
            new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
        );

What this means is that ASP.Net MVC will somehow look up HomeController in your code. Somehow make a new instance of it, and then call the function Index apparently with an id parameter of some sort. And then there are other things like:

RenderView("Categories", categories);
...or..
ViewData["Foobar"]="meh";

And then there are similar things with XAML as well. DataContext is treated as an object and you have to hope and pray that it resolves to the type you want. DependencyProperties must use magic strings and magic naming conventions. And things like this:

  MyData myDataObject = new MyData(DateTime.Now);      
  Binding myBinding = new Binding("MyDataProperty");
  myBinding.Source = myDataObject;

Although it relies more on casting and various magical runtime supports.

Anyway, I say all that to end up here: Why is this so well tolerated in the .Net world? Aren't we using statically typed languages to almost always know what the type of things are? Why is reflection and type/method/property/whatever names(as strings) prefered so much in comparison to generics and delegates or even code generation?

Are there inherit reasons that I'm missing for why ASP.Net's routing syntax relies almost exclusively on reflection to actually resolve how to handle a route? I hate when I change the name of a method or property and suddenly things break, but there don't appear to be any references to that method or property and there are of course no compiler errors. Why was the apparent convenience of magic strings considered "worth it"?

I know there are also commonly statically typed alternatives to some things, but they usually take a backseat and seem to never be in tutorials or other beginner material.

Answer 1

Actually there is a push back in the .NET world against these very things you mentioned. In the first example you gave however, the routing engine is given a convention for mapping the default route. The very fact that the routes are dynamic make it nigh impossible to use a static configuration.

You also mention XAML/WPF, both of which were under development well before generics were introduced into .NET and going back to support generics would have delayed an already very late product (Longhorn/Vista) even further.

There are examples within the ASP.NET MVC framework of using lambda expressions in place of magic strings and the Entity Framework/LINQ takes it even further where the language and framework provides native support for composing SQL queries over a static object graph (instead of constructing magic SQL strings, you get compile time validation of your queries).

For other examples of static configuration see structuremap and other modern dependency injection containers, and other frameworks that need to inspect the object graph at runtime but allow the developer to statically provide hints using lambda expressions.

So the short answer is that historically, .NET did not support static traversal of an object graph until the 3.5 release. Now that we have it, many developers prefer it over magic strings and many have been pushing for even deeper support such as a symbolOf operator that works similar to the typeOf operator.