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

47

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.

Earlz
la source
14
Un dynamisme inutile fait fureur depuis que nos processeurs ont été assez rapides pour l'exécuter.
DeadMG
7
Comment? Je n'ai jamais vu de tels exemples avec LINQ.
DeadMG
6
Mon humble conjecture est que l’alternative correctement typée statiquement est trop gênante. C'est un thème qui revient souvent dans la plupart des systèmes de types: "Nous aimerions le faire dans le système de types, mais ce n'est pas assez expressif." (Ou l'inverse: "Nous avons réussi à exprimer cela dans le système de types, mais cela rendait les choses trois fois plus complexes.") @ GlenH7 Je ne connais pas très bien LINQ, mais les éléments que j'ai utilisés ne sont pas visibles. rien même près de ce que décrit ce post. Envie de donner un exemple?
2
@Earlz Plus important encore, les objets anonymes sont typés statiquement. Il n'y a pas de chaînes magiques, le compilateur connaît le nom et le type de tout ce qui est impliqué. Épargnez pour toute autre utilisation de var.
1
@Earlz, c’est intéressant, même si on pourrait soutenir que la syntaxe lambda est la plus lourde des choses ici. J'imagine qu'ils ont opté pour l'approche de la chaîne magique / convention, car elle est extrêmement simple, "assez bonne" pour beaucoup, et ils peuvent toujours adapter l'outillage pour donner des conseils / une sécurité. C'est un compromis entre sécurité et commodité, à mon humble avis. L'utilisation d'un ViewBag dynamique suggère également cette mentalité (même si je ne suis pas entièrement d'accord avec elle).
Daniel B

Réponses:

31

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.

Michael Brown
la source
3
Le XAML est commenté en tant que tel ... ajouter un support pour les génériques le rendrait encore plus moreo (oui, je sais que le XAML n’est pas conçu pour les humains). De plus, je considère XAML plus comme un langage HTML qu'un langage de programmation réel. Il ne devrait pas se soucier du type d’objets qu’il affiche, mais de la façon de les afficher.
Michael Brown
2
Les génériques sont arrivés en 2.0, mais nous n’avons pas reçu d’expressions avant 3.5 (avec LINQ). Les expressions sont ce qui fait le pouvoir de LINQ et de la communauté. La technique est connue sous le nom de réflexion statique
Michael Brown
1
Bon point sur la réflexion statique. J'avais oublié que cela était introduit dans 3.5
Earlz
2
C'est une excellente réponse et je suis absolument d'accord avec le refoulement. J'évite toutes ces choses comme la peste, car s'il y a une faute de frappe ou un bug, elles ne sont capturées qu'au moment de l'exécution, ce qui signifie qu'elles peuvent très facilement être manquées. Ils rendent également la refactorisation extrêmement différente. Éviter éviter éviter!
Rocklan
2
D'accord sur le refoulement. T4MVC est un projet qui saute à l’esprit qui aspire à supprimer beaucoup de chaînes et à les remplacer par du code fortement typé.
Carson63000