Est-ce une bonne pratique d'utiliser les contrôles utilisateur pour structurer les formulaires WPF même si ces contrôles utilisateur ne sont utilisés qu'une seule fois?
Je développe une application WPF en utilisant MVVM et j'apprends à faire les choses au mieux.
J'ai un formulaire WPF avec des sélecteurs, deux listes avec des champs de recherche et quelques autres éléments. Actuellement, tout est sous une seule forme et cela fonctionne. Mais maintenant, le VM pour ce formulaire a plus de 800 lignes et il n'est pas encore terminé.
Je veux mieux structurer ce formulaire et le code. J'ai pensé aux régions, aux fichiers avec des classes partielles et aux contrôles utilisateur. Je pense que les contrôles utilisateur seraient mieux car ils encapsulent quelques contrôles et logique. Si je utiliserait les contrôles utilisateur, puis la quantité de code dans cette fenêtre et VM serait considérablement réduite.
Pour ce faire, je travaille à travers le livre "Pro WPF 4.5 In C # 4th Edition", Chapter 18 - Custom Elements and the ColorPickerUserControl sample. L'exemple concerne un sélecteur de couleurs avec trois curseurs et il contient 150 lignes de code.
Je pense que je comprends comment cela fonctionne, mais il me semble que la création de contrôles utilisateur, même avec des fonctionnalités très limitées comme dans cet exemple, demande beaucoup de travail. Si j'utilisais ces contrôles plusieurs fois, je comprends que cela aurait du sens de le faire. Mais si j'utilise les commandes une seule fois et que je ne fais cela que pour structurer ma forme, cela semble être beaucoup de travail pour peu de gain.
Ma question est: est-ce une bonne pratique d'utiliser les contrôles utilisateur pour structurer les formulaires même si ces contrôles utilisateur ne sont utilisés qu'une seule fois? Sinon, existe-t-il une meilleure alternative?
Modifier (pas nécessaire de lire, juste plus d'informations): Jusqu'à présent, je n'ai pas écrit de détails parce que je voulais en savoir plus sur le principe mais après avoir lu la réponse intéressante de 17 sur 26, voici quelques détails: forme consiste à sélectionner des titres de musique.
Groupe A: (contrôle utilisateur possible A) concerne le type de sélection comme la sélection par artiste ou album, avec ou sans vidéo, peut-être l'année de publication, etc.
Groupe B: cette liste contient des noms d'artistes qui sont filtrés selon les critères de A. L'utilisateur peut filtrer la liste, c'est-à-dire en affichant uniquement les noms d'artistes contenant "top".
Groupe C: Cette liste affiche les titres de l'artiste sélectionné en B en utilisant également les critères de A (c'est-à-dire audio ou vidéo). Il peut être filtré de manière similaire à B, c'est-à-dire uniquement les titres contenant "vous".
La plupart de la logique se produit dans le VM (DataContext du formulaire). Les listes de A et B proviennent d'une base de données. Les listes sont filtrées et préparées pour la présentation (c.-à-d. Plusieurs titres avec le même nom mais dans des albums différents.) L'utilisateur sélectionne un titre dans la C-List en double-cliquant ou utilise le glisser-déposer dans un autre formulaire WPF.
Ce que je veux: je veux du code lisible afin de pouvoir le modifier facilement. Si je veux ajouter un autre filtre, disons que pour ne montrer que les artistes féminines, ce serait bien si je pouvais simplement aller à l'utilisateur contrôler A et ajouter des cases à cocher pour les artistes masculins et/ou féminins.
Le XAML sous sa forme actuelle ne pose aucun problème, il est bien structuré. Mais le VM a du code pour tout ce qui précède. Certaines choses sont dans le constructeur, certaines dans la section des commandes, quelques propriétés et champs de sauvegarde. Je peux toujours trouver des choses maintenant mais je pense que ce serait mieux si le code était plus structuré. C'est pourquoi je pense aux Contrôles Utilisateur.
J'essaie de suivre MVVM parce que je pense que la logique derrière cela a beaucoup de sens. Mais je ne suis pas un fanatique adepte de toute pratique théorique. I.e. si je peux faire quelque chose en 5 lignes de CodeBehind ou en 50 lignes dans le VM je le ferai probablement dans le CodeBehind. Ma question porte sur le principe de la création de formulaires structurés dans WPF. Le Le formulaire que je décris ci-dessus est un bon exemple, mais la réponse ne doit pas se concentrer sur celui-ci, mais sur l'idée de structurer les formulaires WPF, c'est-à-dire avec (ou sans) les contrôles utilisateur.
A propos de pourquoi je pense que les contrôles utilisateurs sont beaucoup de travail: Ils ont des propriétés de dépendance, des événements routés, etc. Tout cela me semble beaucoup plus compliqué que les propriétés "normales" avec des champs de support et INotify. Mais peut-être que je dois juste m'habituer aux propriétés de dépendance, aux événements routés, etc.
Absolument oui. C'est une bonne idée de la même manière que c'est une bonne idée d'appliquer la séparation des préoccupations sur les classes pour mettre chacune dans son propre afin d'effectuer une seule tâche. Vous ne pouvez avoir qu'une seule instance de cette classe, mais cela n'a pas d'importance. L'optimisation n'est pas en termes de performances du programme mais en termes d'organisation et de "santé" globale du programme.
Vous voulez pouvoir revenir à votre programme un jour et ne pas avoir à parcourir plusieurs centaines de pages de code, même s'il est placé dans des régions (utiliser des régions sur des classes avec beaucoup de code, c'est comme mettre du rouge à lèvres sur un cochon, par le façon). Si vous décidez un jour de l'utiliser ailleurs, vous pouvez le faire gracieusement et sans trop de problèmes.
Ne tentez tout simplement pas de donner à l'utilisateur le contrôle d'accès au formulaire parent. Si vous le faites de cette façon, utilisez des événements pour transmettre des informations au parent, avec le formulaire parent en tant qu'abonné.
C'est une question vraiment difficile à répondre sans voir le code réel. Vous mélangez aussi un peu les termes. Les contrôles utilisateur ne sont pas un mappage 1: 1 avec ViewModels.
Les contrôles utilisateur ont un objectif spécifique dans la vie: ils sont une composition de plusieurs éléments d'interface utilisateur qui sont utilisés comme une unité ensemble. Les contrôles utilisateur sont des sous-sections d'une vue. Ceci est très différent d'un ViewModel, qui contient la logique à laquelle une vue est liée.
Il est peut-être judicieux de diviser votre XAML en plusieurs contrôles utilisateur, tous pilotés par un seul ViewModel. Il est peut-être judicieux de diviser votre code XAML et C # en plusieurs paires View-VM. Peut-être qu'il est logique de le laisser tel que vous l'avez maintenant. Impossible à dire sans voir le code en question.
Quel est votre objectif final ici? La taille du code vous cause-t-elle vraiment de la douleur ou est-ce juste pour suivre une pratique théorique?
Essayez-vous de réduire la taille de vos vues XAML ou la taille de vos ViewModels C #? Ce sont deux tâches très différentes dans le monde WPF MVVM.
800 lignes ne sont pas terriblement grandes pour un VM qui soutient une interface utilisateur qui a n'importe quelle sorte de complexité. La rupture d'un VM peut souvent causer plus de problèmes que il résout. ViewModels prendre des décisions comme "désactiver cette fonctionnalité lorsque cette autre liste est vide". Essayer de fractionner ce type de prise de décision sur plusieurs composants n'a souvent aucun sens et ne fera qu'ajouter de la complexité au code.
Cela dit, il se peut que vous effectuiez du travail dans le VM qui n'a rien à voir avec votre logique ViewModel et qui peut facilement être partitionné dans sa propre classe. Cela réduirait la taille de le ViewModel sans augmenter la complexité globale du code.
Je suppose que c'était juste une façon très longue de dire "Cela dépend, et nous ne pouvons pas le dire sans voir le code en question".
Si moi, qui ne connaissais rien de votre application, je devais ajouter un nouveau champ au-dessus du champ du nom de famille, ou changer l'ordre de quelques champs ... Je trouverais cela facile ou intimidant?
Je ne fais pas confiance aux régions car le compilateur ne vérifie pas si vous égarez quelque chose dans la mauvaise région
Vous devez développer un logiciel dans le but de permettre aux gens de s'appuyer sur ce que vous avez créé.