¿Por qué el mundo .Net parece adoptar cadenas mágicas en lugar de alternativas tipeadas estáticamente?

Entonces, trabajo en .Net. Realizo proyectos de código abierto en .Net. Uno de mis mayores problemas no es necesariamente con .Net, sino con la comunidad y los marcos que lo rodean. Parece en todas partes que los esquemas y cadenas de nombres mágicos se tratan como la mejor manera de hacer todo. Declaración en negrita, pero míralo:

ASP.Net MVC:

Hola ruta mundial:

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

Lo que esto significa es que ASP.Net MVC buscará de alguna manera HomeControlleren su código. De alguna manera, cree una nueva instancia y luego llame a la función Index aparentemente con un idparámetro de algún tipo. Y luego hay otras cosas como:

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

Y luego hay cosas similares con XAML también. DataContextse trata como un objeto y tienes que esperar y rezar para que se resuelva del tipo que deseas. DependencyProperties debe usar cadenas mágicas y convenciones de nombres mágicos. Y cosas como esta:

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

Aunque se basa más en el lanzamiento y en varios soportes mágicos de tiempo de ejecución.

De todos modos, digo todo eso para terminar aquí: ¿Por qué esto es tan bien tolerado en el mundo .Net? ¿No estamos usando lenguajes estáticamente escritos para saber casi siempre qué tipo de cosas son? ¿Por qué se prefiere tanto la reflexión y el tipo / método / propiedad / cualquier nombre (como cadenas) en comparación con los genéricos y los delegados o incluso la generación de código?

¿Hay razones heredadas que me faltan por qué la sintaxis de enrutamiento de ASP.Net se basa casi exclusivamente en la reflexión para resolver realmente cómo manejar una ruta? Odio cuando cambio el nombre de un método o propiedad y de repente las cosas se rompen, pero no parece haber ninguna referencia a ese método o propiedad y, por supuesto, no hay errores de compilación. ¿Por qué la aparente conveniencia de las cuerdas mágicas se considera "vale la pena"?

Sé que también hay alternativas comúnmente escritas estáticamente para algunas cosas, pero por lo general pasan a segundo plano y parecen nunca estar en tutoriales u otro material para principiantes.

En realidad, hay un retroceso en el mundo .NET contra estas mismas cosas que mencionaste. Sin embargo, en el primer ejemplo que dio, el motor de enrutamiento recibe una convención para mapear la ruta predeterminada. El hecho mismo de que las rutas sean dinámicas hace casi imposible usar una configuración estática.

También mencionas XAML / WPF, que estaban en desarrollo mucho antes de que los genéricos se introdujeran en .NET y volver a admitir los genéricos habría retrasado aún más un producto que ya era muy tardío (Longhorn / Vista).

Hay ejemplos dentro del marco ASP.NET MVC de usar expresiones lambda en lugar de cadenas mágicas y Entity Framework / LINQ lo lleva aún más lejos donde el lenguaje y el marco proporcionan soporte nativo para componer consultas SQL sobre un gráfico de objeto estático (en lugar de construir cadenas mágicas de SQL, obtiene la validación en tiempo de compilación de sus consultas).

Para otros ejemplos de configuración estática, vea el mapa de estructura y otros contenedores modernos de inyección de dependencias, y otros marcos que necesitan inspeccionar el gráfico de objetos en tiempo de ejecución, pero permiten al desarrollador proporcionar pistas estáticamente utilizando expresiones lambda.

Entonces, la respuesta corta es que, históricamente, .NET no admitía el recorrido estático de un gráfico de objeto hasta la versión 3.5. Ahora que lo tenemos, muchos desarrolladores lo prefieren a las cadenas mágicas y muchos han estado presionando por un soporte aún más profundo, como un operador symbolOf que funciona de manera similar al operador typeOf.