Code XAML ou C #
Je n'aime pas utiliser XAML. Je préfère tout coder en C #, mais je pense que je fais les choses mal.
Dans quels cas il est préférable d'utiliser XAML et quand utilisez-vous C #? Quelle est votre expérience?
Créer une fenêtre entière en C # peut être un gâchis de code. La meilleure chose à propos de WPF est que XAML vous permet de séparer votre conception de votre logique, ce qui rend le code beaucoup plus facile à lire.
J'utilise C # pour créer des contrôles dynamiques, mais j'ai tendance à conserver ma conception générale, mes storyboards statiques, mes styles, mes modèles de données, etc. en XAML.
Découvrez cette vidéo sur MVVM dans WPF. Si vous souhaitez comprendre comment organiser une application WPF en fonction de ce qui se passe dans XAML, du code arriéré et d'autres abstractions, c'est un excellent point de départ.
Vous pouvez certainement aller trop loin avec XAML. Ceux qui veulent que leur interface utilisateur complète (y compris la logique, les relations de gestion des événements, etc.) définies en XAML manquent probablement.
Le but de XAML est de fournir un format commun permettant de déterminer comment les choses devraient ressembler . Il ne devrait s'agir que d'une description de la manière de disposer les éléments, de les colorer et de les styler visuellement.
Il est vraiment très inutile d'essayer de l'utiliser pour remplacer d'autres aspects de C #, car celui-ci a une longueur d'avance permanente en termes de fonctionnalités de programmation - réutilisation (types et fonctions), référence aux variables, programmation procédurale, etc. même les styles déclaratifs ou fonctionnels.
Personnellement, j'aime bien créer une interface utilisateur avec une expression Linq!
L'absurdité ultime a été atteinte par un échantillon que j'ai vu où ils utilisaient des actions de workflow comme enfants d'un bouton pour fournir le gestionnaire Click, de sorte que l'ensemble du programme était en XAML. Cela semble "cool", mais le problème était qu’il était bien plus laid et illisible que les programmes C # ou VB.NET équivalents et que tout ce qui est prêt à être utilisé en C # doit être remplacé par un équivalent plus verbeux et floconneux. Cette traduction en syntaxe plus moche n’a rien apporté en réalité: c’est le même programme qui n’est que plus hideux. XML constitue une base médiocre pour la syntaxe d'un langage de programmation général. Commencez par le fait que le symbole supérieur à doit être écrit en tant que >!
Dans un univers parallèle, Microsoft a publié C # 3.0 avant la fin du XAML. L'équipe XAML a adopté la syntaxe d'initialisation des objets/listes C # 3.0 au lieu de XML. Et tout ce débat n'a jamais eu lieu.
Mon expérience est que certaines choses sont beaucoup plus rapides à faire en C #, alors que la plupart sont plus rapides à faire en XAML. Quand il faut 5 lignes de code C # pour faire ce qu'une seule ligne de code XAML peut faire, il est assez facile pour moi de choisir lequel est le meilleur.
Fondamentalement, XAML est destiné à exprimer la conception visuelle, C # est destiné à exprimer la logique.
Toute conception visuelle doit être réalisée en XAML, toute logique doit être implémentée en C #.
- Cela permet de donner à un concepteur le design visuel qui lui convient, sans se soucier des modifications de la logique, ni même de remplacer le design visuel complet au moment de l'exécution à l'aide de loose-XAML.
- Cela signifie également que vous pouvez remplacer la logique ou la conception visuelle sans «casser» l'une ou l'autre.
- La connexion entre les deux doit se faire avec des liaisons de données et des liaisons de commande.
La pratique que j'utilise est:
1. Définissez le modèle (le modèle d'objet de données métiers) dans un code C # séparé.
2. Définissez les parties constantes de la vue (les parties constantes de l'interface utilisateur graphique , Par exemple les fenêtres, les menus, ...) en XAML (utilisez de préférence Blend et non VS pour cela).
* Ne définissez pas le style (couleurs, polices, ...) ici.
* N'écrivez pas de gestionnaires d'événements pour les boutons (dans la plupart des cas) dans code-behind-the-XAML, utilisez plutôt les liaisons de commande.
3. Définissez la manière dont le modèle est présenté dans la vue (l'interface graphique permettant d'afficher/de modifier les objets de données) à l'aide de "ResourceDictionary" XAML situés dans des fichiers distincts.
- Écrivez en utilisant blend, puis ajoutez des liaisons à XAML en utilisant VS (le complément Resharper de Jetbrains pour VS aidera à la liaison des expressions).
- Si les types d'objet ne sont pas connus au moment de la conception, vous pouvez utiliser "loose-XAML" et placer le fichier XAML dans un dossier dans lequel des fichiers peuvent être ajoutés/modifiés sans recompilation.
4. Créez une connexion entre le modèle et la vue (un contrôleur/modèle de vue) en C # qui:
* Crée les vues nécessaires (pour les objets dynamiques)
* Data lie la vue au modèle (définit la source de données de la vue comme objet pertinent dans le modèle).
* Implémente les commandes
* Command-lie la vue aux implémentations de commande en elle-même
5. Dans Application.xaml, supprimez StartupUri = "MainWindow.xaml" et ajoutez Startup = "ApplicaitonStartUp" à la place.
Dans le gestionnaire d'événements ApplicationStartUp ():
* Chargez tous les XAML libres que vous avez
* Créer le contrôleur
* Créer la fenêtre principale
* Créer le modèle
* Connecter le contrôleur au modèle et à la fenêtre principale
* Afficher la fenêtre principale
* (Enregistrez le modèle, le contrôleur et la fenêtre principale dans des champs privés ici pour vous assurer qu'ils sont tous conservés)
6. Ajoutez un style (couleurs, polices) à un fichier XAML distinct sous un ResourceDictionary (en utilisant un mélange pour cela ou achetez un fichier de thème/skin XAML prêt à l'emploi).
L'envie de vouloir écrire vos interfaces utilisateur en C # au lieu de XAML n'est en réalité qu'une manifestation de votre degré de confort dans XAML.
Pour moi, c’est un objectif personnel: écrire le moins de code possible. En termes simples, le code derrière est difficile à tester, mais peut (et le fait généralement) inclure une logique qui n’est pas testée. XAML est déclaratif (comme HTML) et n'inclut aucune logique. Il n'y a donc rien à tester par unités. Je conserve mon code de vue en XAML et ma logique de vue dans mon ViewModel (MVVM), très facile à tester.
Une fois que vous serez plus à l'aise avec XAML, plus vous réaliserez ses avantages par rapport à la construction de vues dans un code de procédure ... En utilisant un modèle tel que MVVM, vous allez encore plus loin et vous réalisez que le code derrière n'est utile que dans de rares cas.
XAML, MXML tout cela fonctionne tant que vous développez une interface utilisateur simple avec une complexité moyenne. Une fois que votre interface devient complexe et plus riche, les liaisons de données automatiques causeront plus de problèmes que leurs avantages. Le but de XAML n’est pas de rendre la programmation facile, mais bien de séparer l’UI de la logique afin que l’outillage de l’UI puisse être facile.
Aucune liaison de données, aucun gestionnaire d'événements .. supposez que vous ne verrez plus jamais votre code XAML et écrivez du code ..
XAML est la présentation. La liaison de données n'est pas une présentation. sa logique de présentation. mettre toute la logique de présentation dans le code derrière (liaison de données et gestionnaires). Les développeurs possèdent du code, les concepteurs possèdent XAML. si vous êtes un développeur et que vous touchez XAML, déplacez cette partie dans le code derrière.
nous pouvons aussi écrire des applications WPF sans XAML.
Merci Vinoth Kumar R (La liaison de données Flex MXML a suffisamment été utilisée.)
L’un des avantages du XAML est la séparation de la présentation et de la logique. Cette séparation n’est pas seulement théorique, mais aussi pratique. Dans mon cas, la plupart de mes interfaces utilisateur sont maintenant gérées par un concepteur. Ce concepteur utilise blend et ne connaît pas le c #, n'a aucun intérêt à apprendre le c # et ne devrait pas en avoir besoin. Ce designer est un vrai designer, un artiste, qui sait utiliser ces outils pour rendre les choses vraiment belles. En gros, ma phylosipie est la suivante: plus j'utilise XAML, moins je dois travailler sur l'interface utilisateur, car il peut le faire. Cela a bien fonctionné pour nous. En général, je conçois mon contrôle de manière à ce qu'il soit sans apparence, donne-leur un aspect basique, utilisez le DataContext pour lier mon objet (en fait, les DataTriggers sont un excellent moyen de réduire le code). En conséquence, je vais souvent vérifier mon code, revenir le lendemain, le synchroniser, et l'interface sera complètement différente, mais tout fonctionne toujours !!!
Bien sûr, il a fallu au moins un an et demi pour y arriver, mais maintenant ce modèle semble fonctionner et notre interface utilisateur a l'air Kick A ##, notre application mérite des éloges, et je fais peu de travail sur l'interface utilisateur elle-même et commence à travailler. des choses plus cool. Pour résumer, je pense que le code caché est peut-être un peu plus centré sur les développeurs et oublie tout un groupe qui pourrait en tirer profit, gagner de l’argent et gagner sa vie avec WPF, à savoir les concepteurs.
Bien sûr, il faut encore parfois un développeur pour faire chanter et danser XAML/WPF, et il est parfois nécessaire d'informer les concepteurs sur la bonne façon de faire les choses, mais je pense que l'investissement en vaut la chandelle à maintes reprises projets de grande envergure (peut-être pas si bref
La chose la plus importante à garder à l’esprit est que XAML est destiné à la présentation. Toute votre présentation devrait être dans le XAML. Si vous avez une logique, vous la gardez en dehors de votre XAML - dans votre C #.
Imaginez que vous remplaciez votre fichier XAML par un fichier LOOKS complètement différent, tout en utilisant les mêmes données.
Il ne s'agit pas que de vous, il s'agit également de votre équipe, dont certains peuvent être des designers.
XAML et C # constituent un très bon moyen de séparer la logique de la conception, comme décrit précédemment.
Pour un programmeur typique, la manière de programmer est vraiment modifiée en utilisant WPF, en supposant que le programmeur provient d'un arrière-plan C++, VB, WinForms, ATL et MFC, un arrière-plan dans lequel l'interface utilisateur n'était pas aussi naturelle que la logique avec XAML et C#.
Il faut un certain temps pour s'habituer à cette façon de programmer, mais obtenir de plus en plus d'expérience est vraiment efficace.
Avant de commencer, il est vraiment bon d’apprendre le modèle MVVM et de lancer des tutoriels pour en comprendre la force, ainsi que pour en comprendre les avantages.
Applications WPF et C # basées sur les avantages du modèle MVVM:
1. Expérience utilisateur et convivialité En séparant la logique de l'interface utilisateur, il est plus naturel de faire appel à un concepteur dédié pour la conception et les animations de l'interface utilisateur. De cette façon, le programmeur peut se concentrer sur la logique et la solution technique tandis que l’interface utilisateur est conçue par une personne connaissant le design. Cela a posé problème à de nombreux éditeurs de logiciels, tout au moins dans l’industrie que les programmeurs sont actuellement. la fois où l'interface utilisateur est également conçue et qui s'est traduite par beaucoup d'assistance, de maintenance et d'applications efficaces.
Il y a une probabilité plus élevée que cela aboutisse à des applications plus conviviales en utilisant une personne ayant une expérience en utilisabilité centrée sur l'utilisation plutôt que sur la solution technique. Il existe un livre vraiment intéressant sur ces exemples, User Interface Design for Programmers, de Joel Spolsky.
En utilisant le modèle MVVM pour l'application XAML, il y a de fortes chances que nous voyions plus d'applications conviviales.
2. Maintenance La maintenance, qui coûte cher en développement logiciel. On peut avoir l’impression que le modèle MVVM est une lourde charge au début, mais bien que des fonctions soient ajoutées et que l’application devienne plus complexe et plus avancée, elle devient plus avantageuse. Vous verrez qu'il est vraiment facile de maintenir une telle application. Pour un aperçu général, vous pouvez regarder cette vidéo:
3. Combinaison de compétences Un concepteur dédié et un programmeur dédié travaillant en équipe pour obtenir de meilleurs résultats constituent un très bon moyen de mélanger les compétences. Au lieu de n'embaucher que des programmeurs, les organisations doivent combiner leurs compétences pour fournir les meilleurs résultats.
4. Possibilité pour les programmeurs intéressés par la conception Enfin, il est possible d'implémenter des applications sophistiquées dans l'environnement Windows. Si vous êtes un programmeur intéressé par la conception, Microsoft Expression Blend ouvre vraiment des possibilités pour apprendre et réaliser des applications sophistiquées et utiles au design agréable.
XAML et C #, MVVM ou non, peuvent comporter des risques, mais les grandes possibilités et la flexibilité qu’il offre peuvent également être un inconvénient. En laissant le programmeur perdre le contrôle de ce nouvel environnement d'interface utilisateur simple, les applications peuvent se retrouver avec un large spectre d'animations, de couleurs, de tout ce que ce nouvel environnement fournit. Rappelez-vous comment vous avez ajouté des contrôles d'interface utilisateur dans l'environnement C++ et ATL.
Néanmoins, les avantages sont encore plus nombreux et j'espère que vous obtiendrez une inspiration pour utiliser XAML au lieu de C # pour l'interface utilisateur. Lorsque je m'y habituerai, je suis convaincu que vous l'aimerez.
Un lien vers un bon tutoriel: Tutoriel MVVM XAML C #
Il semble qu'aucune réponse ne soit encore donnée à un point important: https://msdn.Microsoft.com/en-us/library/windows/apps/xaml/hh465340.aspx
XAML est juste un code de procédure (seulement plus facile)
<Grid x:Name="ContentPanel" Margin="12,0,12,0">
<Button Height="72" Width="160" Content="Click Me" />
</Grid>
"Ce qui suit montre comment ce code XAML peut être partiellement remplacé par du code écrit en C # ou Visual Basic."
// Initialize the button
Button myButton = new Button();
// Set its properties
myButton.Width = 160;
myButton.Height = 72;
myButton.Content = "Click Me";
// Attach it to the visual tree, specifically as a child of
// a Grid object (named 'ContentPanel') that already exists. In other words, position
// the button in the UI.
ContentPanel.Children.Add(myButton);
Si vous avez utilisé des formulaires Windows par exemple, vous vous souviendrez probablement que le concepteur de formulaires Windows générait un fichier .designer.cs contenant du code similaire à l'exemple du lien ci-dessus. Ce type de code déclaratif est bien mieux représenté dans XAML que C #.
Pour toute application non-jouet, vous devriez TOUJOURS préférer que XAML définisse l’UI et le connecte à la logique de manière MVVM.
Je suis originaire du développement Web et j'apprends actuellement WPF/Silverlight. Pour moi, le modèle XAML a beaucoup plus de sens que WinForms. Je traite le XAML comme s'il s'agissait de HTML et les fichiers .cs comme un code-behind.
Toute logique doit être en code, quel que soit le langage de programmation que vous utilisez en programmation informatique. XAML ne devrait jamais remplacer cela, même dans ControlTemplate bien que ce soit Nice mais il est beaucoup plus facile de tester et de déboguer le code.
J'aime le code propre, moins j'ai de code, plus il est propre. Le code peut être écrit de mille façons, le XAML étant plus restrictif. XAML est doué pour couper le code, le cas échéant. Si je peux mettre quelque chose en XAML, je le ferai. Les outils peuvent lire le XAML et faire des choses avec. Beaucoup moins avec du code. Les outils et les structures gérant le XAML évolueront et s'amélioreront, en travaillant davantage et mieux avec le XAML existant. Je ne peux pas en dire autant du code. Plus le XAML évolue, plus nous pourrons définir nos applications de manière déclarative.
Pour moi, utiliser XAML, c'est comme utiliser LINQ. Si je peux écrire une déclaration d'une ligne facile à lire et laisser un cadre décider de la meilleure façon de mettre en œuvre ce que je veux, je me sens bien. J'essaie vraiment, autant que je peux, d'utiliser des déclarations de ce que je veux au lieu de coder en dur comment je veux que ce soit fait. F # est un autre bon exemple de ce paradigme.
Ne pas mentionner que vous pourrez faire plus dans Xaml2009 que cela doit être fait dans le code derrière maintenant.
Malheureusement, BAML ne prendra pas totalement en charge xaml 2009 dans la période de référence 2010, vous ne pouvez donc pas compiler xaml dans la période de 2010. Et devra attendre une version ultérieure de blend pour effectuer la boucle de conception complète. (plus tard que 3)
Douglas
XAML peut être considéré comme similaire à une combinaison de XHTML et CSS ou XML et XSL utilisés pour la structure et la conception. Toute forme de logique devrait être en C #. Ainsi, la structure et la conception sont séparées de la logique. Votre code devrait aussi être plus propre en utilisant cette approche. Une autre chose positive est que les tâches peuvent être plus faciles à séparer entre les concepteurs et les programmeurs.
Une dernière chose ... c'est la définition de XAML de MSDN:
Le langage XAML (Extensible Application Markup Language) est un langage de balisage pour la programmation d'applications déclarative. Windows Presentation Foundation (WPF) implémente un chargeur XAML (Extensible Application Markup Language) et fournit une prise en charge du langage XAML (Extensible Application Markup Language) pour les types Windows Presentation Foundation (WPF), ce qui vous permet de créer la majorité de l'interface utilisateur de votre application dans Extensible Application Markup. Langage (XAML). En outre, le Kit de développement logiciel (SDK) comprend un outil d'édition XAML (Extensible Application Markup Language) appelé XAMLPad. Vous pouvez utiliser cet outil pour expérimenter le langage XAML (Extensible Application Markup Language) en temps réel.
Certaines choses sont plus faciles à maintenir ou à déboguer dans le code.
Programmer WPF en C # avec un style fluide aide à réduire la taille et la complexité du code. Voir cette réponse pour un exemple d'utilisation d'un style fluide avec WPF.