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:


Hello world route:

            "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);

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.

  • 17
    Pointless dynamism has been all the rage ever since our CPUs were fast enough to execute it.
    – DeadMG
    Feb 14, 2013 at 18:52
  • 7
    How so? I've not seen any such examples with LINQ.
    – DeadMG
    Feb 14, 2013 at 19:00
  • 6
    My humble guess is that the properly statically typed alternative is too freaking inconvenient. That's a theme that turns up a lot with most type systems really: "We'd like to do this in the type system, but it's not expressive enough." (Or the inverse: "We successfully expressed this in the type system, but it made things three times as complex.") @GlenH7 I'm not terribly familiar with all of LINQ, but the bits I've used don't exhibit anything even near what this post describes. Care to give an example?
    – user7043
    Feb 14, 2013 at 19:00
  • 2
    @Earlz More importantly, anonymous objects are statically typed. There are no magic strings, the compiler knows the name and type of everything involved. Save for every other use of var.
    – user7043
    Feb 14, 2013 at 19:02
  • 1
    @Earlz that's interesting, although one could argue that the lambda syntax is the additional bloat here. My guess is they went with the magic string / convention approach because it's dead simple, "good enough" for many, and they can always adapt the tooling to give some guidance / safety. It's a trade off between safety and convenience, IMHO. The use of a dynamic ViewBag also hint at this mentality (not that I fully agree with it).
    – Daniel B
    Feb 15, 2013 at 16:18

2 Answers 2


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.

  • 3
    XAML is verbose as it is...adding support for generics would make it even moreso (yes I know the whole XAML isn't made for humans Argument). Besides, I see XAML as more akin to HTML than an actual programming language. It shouldn't care about the type of the objects it is displaying, just how to display it. Feb 14, 2013 at 21:22
  • 2
    Generics arrived in 2.0, but we didn't get Expressions until 3.5 (with LINQ). Expressions are what power LINQ and the community has taken that power and run with it. The technique is known as static reflection Feb 14, 2013 at 21:25
  • 1
    Good point about static reflection. I forgot about that being introduced in 3.5
    – Earlz
    Feb 14, 2013 at 21:28
  • 2
    This is a great answer and I definitely agree with the pushback. All of these things I avoid like the plague because if there's a typo or bug they are only caught at runtime, meaning they can very easily be missed. They also make refactoring extremely different. Avoid avoid avoid!
    – Rocklan
    Feb 14, 2013 at 22:13
  • 2
    Agree on the pushback. T4MVC is a project which leaps to mind that aspires to remove a lot of strings and replace them with strongly typed code. Feb 14, 2013 at 22:27

Asp.Net MVC is strongly inspired by frameworks like Django and Rails originating from dynamically typed languages. Therefore it adopts a number of patterns and conventions which feel a lot more dynamic than what is usual in the .net culture, for example heavy use of reflection and dynamic objects. This was probably a deliberate strategic decision by MS because .net was losing mind-share among web developers compared to these platforms.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.