Pourquoi le monde .Net semble-t-il adopter des chaînes magiques au lieu d’alternatives statiques?

Donc, je travaille en .Net. Je fais des projets open source en .Net. L’un de mes plus gros problèmes n’est pas nécessairement lié à .Net, mais à la communauté et aux cadres qui l’entourent. Il semble partout que les systèmes de nommage et les chaînes de caractères magiques soient considérés comme le meilleur moyen de tout faire. Déclaration audacieuse, mais regardez-la:

ASP.Net MVC:

Bonjour la route du monde:

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

En d'autres termes, ASP.Net MVC recherchera HomeControllerdans votre code. En quelque sorte, créez-en une nouvelle instance, puis appelez la fonction Index apparemment avec un idparamètre quelconque. Et puis il y a d'autres choses comme:

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

Et puis, il y a des choses similaires avec XAML. DataContextest traité comme un objet et vous devez espérer et prier que cela se résolve au type que vous voulez. DependencyProperties doit utiliser des chaînes et des conventions de dénomination magiques. Et des choses comme ça:

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

Bien que cela repose davantage sur le casting et divers supports d’exécution magiques.

En tout cas, je dis tout cela pour en arriver là: pourquoi est-ce si bien toléré dans le monde .Net? N'utilisons-nous pas des langages statiquement typés pour savoir presque toujours quel type de choses sont? Pourquoi la réflexion et le type / méthode / propriété / quels que soient les noms (en tant que chaînes) sont-ils tellement préférés par rapport aux génériques et aux délégués ou même à la génération de code?

Existe-t-il des raisons héritées qui me manquent pour lesquelles la syntaxe de routage d'ASP.Net repose presque exclusivement sur la réflexion afin de déterminer comment gérer un itinéraire? Je déteste quand je change le nom d'une méthode ou d'une propriété et que soudainement des choses se cassent, mais il ne semble pas y avoir de références à cette méthode ou à cette propriété et il n'y a bien sûr aucune erreur de compilation. Pourquoi la commodité apparente des cordes magiques était-elle considérée comme "valant la peine"?

Je sais qu'il existe également des alternatives typées statiquement à certaines choses, mais elles prennent généralement une banquette arrière et ne semblent jamais figurer dans des tutoriels ou autres supports pour débutants.

En réalité, le monde .NET est opposé à ces choses que vous avez mentionnées. Toutefois, dans le premier exemple que vous avez donné, le moteur de routage se voit attribuer une convention pour mapper la route par défaut. Le fait même que les routes soient dynamiques rend presque impossible l'utilisation d'une configuration statique.

Vous avez également mentionné XAML / WPF, qui étaient tous deux en cours de développement bien avant l’introduction des génériques dans .NET et le fait de revenir au support générique aurait retardé davantage un produit déjà très en retard (Longhorn / Vista).

Le framework ASP.NET MVC contient des exemples d'utilisation d'expressions lambda à la place de chaînes magiques et Entity Framework / LINQ va encore plus loin dans les domaines où le langage et le framework fournissent un support natif pour la composition de requêtes SQL sur un graphe d'objet statique (au lieu de la construction). Magic SQL, vous obtenez une validation à la compilation de vos requêtes).

Pour d'autres exemples de configuration statique, voir Structemap et d'autres conteneurs d'injection de dépendances modernes, ainsi que d'autres frameworks qui doivent inspecter le graphe d'objet au moment de l'exécution, mais permettent au développeur de fournir de manière statique des astuces à l'aide d'expressions lambda.

Donc, la réponse courte est qu'historiquement, .NET ne supportait pas la traversée statique d'un graphe d'objet jusqu'à la version 3.5. Maintenant que nous l’avons, de nombreux développeurs le préfèrent aux chaînes magiques et beaucoup ont réclamé un support encore plus profond, tel qu’un opérateur symbolOf qui fonctionne de la même manière que l’opérateur typeOf.