Pourquoi avoir un code utilisateur / manuscrit minimal et tout faire en XAML?

Je sens que la communauté MVVM est devenue trop zélée comme les programmeurs OO dans les années 90 - c'est un terme inapproprié MVVM est synonyme de pas de code. De ma question fermée StackOverflow :

Plusieurs fois, je tombe sur des articles sur quelqu'un essayant de faire l'équivalent en XAML au lieu de code derrière. Leur seule raison étant qu'ils veulent garder leur code derrière «propre». Corrigez-moi si je me trompe, mais ce n'est pas le cas:

XAML est également compilé - en BAML - puis lors de l'exécution doit être analysé dans le code de toute façon. XAML peut potentiellement avoir plus de bogues d'exécution car ils ne seront pas détectés par le compilateur au moment de la compilation - à partir d'une orthographe incorrecte - ces bogues sont également plus difficiles à déboguer. Il y a déjà du code derrière - qu'on le veuille ou non InitializeComponent (); doit être exécuté et le fichier .gics dans lequel il se trouve contient un tas de code bien qu'il puisse être masqué. Est-ce purement psychologique? Je soupçonne que ce sont des développeurs qui viennent d'un fond Web et qui aiment le balisage par opposition au code.

EDIT: je ne propose pas de code derrière au lieu de XAML - utilisez les deux - je préfère faire ma liaison en XAML aussi - je suis juste contre de faire tous les efforts pour éviter d'écrire du code derrière esp dans une application WPF - ce devrait être une fusion de à la fois pour en tirer le meilleur parti.

MISE À JOUR: Ce n'est même pas l'idée de Microsoft, chaque exemple sur MSDN montre comment vous pouvez le faire dans les deux.

Je n'ai jamais entendu parler de quelqu'un suggérant de tout mettre en XAML.

En fait, ce serait une idée terrible, OMI.

Le problème, historiquement, provenait des applications Winforms ayant une logique dans leur code qui n'y appartenait pas, car c'était de la logique . C'est de là que vient l'importance de la VM. Il vous permet d'isoler les pièces qui relient la vue au modèle.

Par conséquent, la vue est laissée pour gérer uniquement ce qui fonctionne le mieux, à savoir l'interface utilisateur.

Maintenant, s'il vous arrive d'avoir des situations où votre interface utilisateur nécessite du code, alors allez-y par tous les moyens et mettez-le dans votre code derrière. Cependant, je dirais que pour 95% des scénarios, vous feriez probablement mieux de laisser l'interface utilisateur dans le fichier de balisage, et si vous avez besoin de code, c'est probablement une logique que vous essayez d'écrire qui est plus adéquatement laissé au modèle de vue. Les exceptions à cela sont des choses telles que les comportements, mais ce sont des animaux complètement séparés, et nécessitent une place spéciale (c'est-à-dire pas dans votre code derrière).

Pour répondre directement à votre question, et en supposant que lorsque vous dites "code", dans chaque cas, vous vous référez spécifiquement au code-behind (code qui se trouve sur une classe de contrôle visuel), la raison est que votre interface utilisateur peut être entièrement implémentée et manipulé dans Blend, en utilisant une seule technologie. L'hypothèse est que vos concepteurs UX ne sont pas des développeurs et ne veulent pas travailler dans le code, et qu'ils sont des experts en mise en page et XAML par opposition à des experts en codage. Si vous implémentez tout sans code-behind, vous pouvez donner à ces types de concepteurs les outils dont ils ont besoin pour travailler entièrement dans leur langage.

Il fournit une séparation nette entre la programmation impérative et la conception déclarative.

C'est la raison principale de l'existence de "comportements" dans Silverlight et WPF - au lieu de plonger du code dans le code-behind, faire d'un comportement son propre petit module réutilisable. Si vous le faites, Blend vous offre l'avantage de pouvoir le faire glisser et le déposer sur un contrôle. Maintenant, au lieu d'avoir une partie mobile unique vers un contrôle autrement tout en XAML, vous avez résumé les parties mobiles dans un joli conteneur qui peut être manipulé à l'aide d'outils de conception.

D'après mon expérience, cela revient souvent à essayer d'utiliser une logique compliquée dans les déclencheurs XAML afin de la garder à l'écart du code, alors que l'approche la meilleure et la plus simple serait de ne mettre cette logique dans aucune - elle appartient à la vue -modèle.

L'un des plus grands avantages de faire tout ce que vous pouvez dans xaml est qu'il conserve tous les comportements au même endroit. Chaque fois que le développeur doit sauter entre le xaml et le code, il devient plus difficile de le comprendre.

J'ai fait partie d'une équipe WPF qui n'a pas fait de la réduction du code-behind une priorité. Il y a eu plus de quelques fois que le débogage a été beaucoup plus difficile car un gestionnaire d'événements manipulait le contrôle et ce n'était pas immédiatement apparent car le comportement était dispersé dans deux fichiers.

Cela dit, je pense que vous avez raison de penser que parfois il vaut mieux faire des compromis sur le principe de conception. Certaines choses sont très difficiles à faire dans xaml. J'ai passé des heures, voire des jours, à essayer de faire fonctionner un comportement dans xaml que j'aurais pu faire en beaucoup moins de temps en utilisant le code-behind. J'en suis venu à considérer le code-behind comme un dernier recours, mais je ne dirais jamais à quelqu'un qu'il ne devrait jamais l'utiliser. C'est juste un autre compromis qu'un bon ingénieur doit comprendre.

edit: D'après les commentaires, il semble que mon message est interprété comme argumentant contre xaml. Mon intention était de faire valoir le contraire. Le xaml pur est toujours préférable car il conserve tous les comportements au même endroit. Un mélange de xaml et de code-behind peut être alambiqué, donc minimiser le code-behind est idéal. Xaml est préférable au code-behind pur pour de nombreuses raisons. WPF et Silverlight sont conçus pour être écrits en xaml.

Je n'ai qu'une connaissance très superficielle de XAML, mais cela me déconcerte que le compilateur ne détecte pas les fautes de frappe.

La différence fondamentale est que XAML est déclaratif , tandis que C # par exemple est impératif.

Tout simplement:

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

contre.

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

Le code supérieur crée vraiment une hiérarchie par effets secondaires, tandis que le code inférieur la déclare simplement. Il convient également de noter que, par exemple, si la addChildméthode peut être renommée, la relation enfant-parent est au cœur du modèle sémantique et est représentée telle quelle dans l'extrait déclaratif. Il est très loin de l'implémentation, ce qui permet beaucoup d'optimisation en dessous, comme l'instanciation paresseuse, de manière totalement transparente.
La programmation déclarative présente un certain nombre d'avantages. Il est plus concis, expressif et très proche de votre modèle. J'irais aussi loin que cela est préférable.

Cependant, cela ne signifie pas, vous devez essayer de tout poinçonner en XAML. C # a de nombreuses constructions de haut niveau qui permettent un style déclaratif.

En fin de compte, vous voulez que votre code soit court et facile à lire. Donc, si vous pouvez réaliser la même chose en C # avec moins de code qu'en XAML, l'utilisation de C # est logique. Gardez à l'esprit que, cependant, le code XAML est plus "portable" dans le sens où il est beaucoup moins vulnérable aux changements dans les composants utilisés, en faisant abstraction du framework .NET (par exemple les détails de la façon dont les liaisons sont implémentées).