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

46

Por lo tanto, trabajo en .Net. Realizo proyectos de código abierto en .Net. Uno de mis mayores problemas con esto no es necesariamente con .Net, sino con la comunidad y los marcos a su alrededor. Parece que en todas partes los esquemas y cadenas de nombres mágicos son tratados como la mejor manera de hacer todo. Declaración audaz, pero míralo:

MVC ASP.Net:

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 HomeController en tu código. De alguna manera, cree una nueva instancia de él, y luego llame a la función Index aparentemente con un parámetro id 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. DataContext se trata como un objeto y usted tiene que esperar y rezar para que se adapte al tipo que desea. 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 de ejecución mágicos.

De todos modos, digo todo eso para terminar aquí: ¿Por qué esto es tan bien tolerado en el mundo .Net? ¿No estamos usando lenguajes tipificados estáticamente 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 hereditarias que me falten 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 consideró "valiosa"?

Sé que también hay alternativas tipificadas de forma estática para algunas cosas, pero por lo general se quedan atrás y parece que nunca aparecen en tutoriales u otro material para principiantes.

    
pregunta Earlz 14.02.2013 - 19:33

1 respuesta

30

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

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

Hay un ejemplo dentro del marco MVC de ASP.NET sobre el uso de expresiones lambda en lugar de cadenas mágicas, y Entity Framework / LINQ lo lleva aún más lejos cuando el lenguaje y el marco proporcionan soporte nativo para componer consultas SQL sobre un gráfico de objetos estáticos ( En lugar de construir cadenas de SQL mágicas, obtienes la validación en tiempo de compilación de tus 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 sugerencias de forma estática utilizando expresiones lambda.

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

    
respondido por el Michael Brown 14.02.2013 - 22:04

Lea otras preguntas en las etiquetas