MVC HTML Helpers et Lambda Expressions

Je comprends la plupart des requêtes Lambda, mais lorsque j’essaie d’apprendre MVC et que je vois les modèles Scaffolding par défaut, ils utilisent des expressions Lambda pour de nombreux composants.

Un exemple est le DisplayFor HTML Helper. Le code va @Html.DisplayFor(model => model.name)

J’espère que personne ne pense que c’est une question stupide, c’est juste que bien que je (pense que je comprenne) la plupart des expressions lambda, elles ne “coulent” pas comme du code normal et je dois y penser assez difficilement à comprendre ce qui se passe réellement!

Donc la question est vraiment,

1) Y at-il un avantage qui leur manque en utilisant des requêtes Lambda pour ces aides HTML?

2) Autant que je sache, le DisplayFor ne sera jamais raccordé à un élément. Alors, pourquoi ne s’agit-il pas simplement de @Html.DisplayFor(model.name) ou similaire?

Et s’il vous plaît donner toute autre information qui peut rendre un débutant MVC meilleur!

Avant de répondre à vos deux points, je pense que vous devez comprendre ce que sont réellement les expressions lambda.

En .Net, les expressions Lambda utilisées de cette manière s’appellent des arbres d’expression. De MSDN :

Les arbres d’expression représentent le code dans une structure de données en forme d’arborescence, où chaque nœud est une expression, par exemple, un appel de méthode ou une opération binary telle que x

Ce sont essentiellement des structures de données qui décrivent ce qui est transmis, plutôt que les valeurs des données transmises. Cela signifie que lorsque vous appelez Html.DisplayFor(x => model.Name) il passe dans une structure de données qui “J’appelle cette méthode pour la propriété Name de la structure de données xxxx (où xxxx est le type de structure de données qui représente votre modèle de vue).

DisplayFor examine ensuite ces données et constate que le nom de la propriété Name est well Name, il examine tous les atsortingbuts de la propriété pour déterminer si des annotations de données y sont attachées, puis examine la valeur pour déterminer le mode de représentation. l’affichage pour la valeur. C’est un peu compliqué jusqu’à ce que vous ayez la tête autour de vous, mais une fois que vous aurez consulté la page MSDN et réfléchi, vous obtiendrez un aha! moment comme je l’ai fait, et ça va tout à coup avoir un sens 🙂

En ce qui concerne votre question n ° 1, l’utilisation des expressions lambda présente l’avantage de vous permettre de vérifier le temps de compilation de vos propriétés. Par exemple, si vous renommez ViewModel.Name en ViewModel.ClientName , tous vos Html.DisplayFor(x => model.Name) ne seront pas compilés, ce qui vous Html.DisplayFor(x => model.Name) les modifier. Si vous n’utilisez pas d’expressions lambda, tous vos Html.Display() fonctionneront, mais vous obtiendrez des bogues cachés avec la liaison de modèle qui ne seront pas immédiatement évidents quant à ce qui ne va pas.

Pour répondre à la question n ° 2, la raison est la même que ma description des arbres d’expression. Sans utiliser lambdas, vous transmettez simplement la valeur de Model.Name sans aucune information sur la propriété elle-même. Par conséquent, elle ne sait pas que le nom de la propriété Model.Name est Name , il ne voit que la valeur de chaîne.

Vous trouverez un autre bon article sur Expression Trees ici . Comprendre les arbres d’expression ouvre beaucoup de puissance dans .Net 🙂

Vous avez la possibilité d’utiliser une alternative, semblable à celle que vous avez ci-dessus. Dans ce cas, il s’agirait en réalité de @Html.Display("name") sans la partie “Pour” et du nom de propriété du modèle transmis sous forme de chaîne. Ceci est une alternative OK. Si le nom de votre propriété change bien, cela se produira à l’exécution.

J’aime les lambdas parce que je suis un junkie du refactoring qui renomme constamment les choses. En activant la compilation de vues, je peux ensuite m’appuyer sur le compilateur pour m’aider à trouver les endroits nécessaires à la mise à jour de mes vues.