7
votes

Est-ce juste moi, ou est-ce que WPF est un gâchis de databinding et d'ivenvereurs personnalisés?

Sérieusement, il semble que cela ressemble à chaque fois que je veux faire de mes éléments d'interface utilisateur se parler, je finirai de coder une nouvelle, personnalisée, Igueconverter :(. Quelqu'un me dise que je le fais mal, s'il vous plaît!

Exemples:

  • Je voulais que un bouton soit activé uniquement si ma zone de texte contenait une URI valide. Génial, le temps de coder un uiisvalidconverter !
  • Oh oups, je voulais aussi le désactiver pendant que je traite quelque chose. Je suppose que maintenant j'ai besoin de coder un uiisvalidandboolfalsMulticoverter !
  • Je souhaite afficher une liste de fichiers dans un certain répertoire (spécifié par une zone de texte) dans une liste de liste. Je suppose que j'ai besoin d'un DirectoryPathtofilelist Converter!
  • Oh Hey, je veux des icônes pour chacun de ces fichiers dans la liste de réception. Temps pour un FileInfotobitMap Convertisseur!
  • Je veux que mon statut soit rouge si ma chaîne d'état contient "Erreur" et vert sinon. YAY, je reçois la coeur d'un StassTringTosolidColorbrushconverter !

    Je pense vraiment que ce n'est pas beaucoup mieux que les anciens formes de Windows constituent une méthode de câblage manuellement en utilisant textchanged événements (ou autre). Ce que je suppose, c'est toujours une option. Est-ce ce que les gens font réellement, peut-être, et j'essaye trop difficile de faire tout ce qui s'inscrit dans le paradigme de Databinting?

    Alors oui, dites-moi s'il s'agit vraiment de la façon dont le codage WPF est --- ou si je le fais mal, et si oui, ce que je devrais faire.


1 commentaires

Plus près répondait probablement au niveau de frustration dans la question de ce type. La façon dont vous faites cela semble très frustrante. C'est pourquoi vous devez vérifier MVVM. Prend la frustration immédiatement.


3 Réponses :


10
votes

Votre approche est parfaitement valide (bien que j'utilise un multibinage pour le deuxième exemple, plutôt qu'un tel convertisseur spécialisé), mais en plaçant toute votre logique dans le XAML, vous produisez un couplage très élevé entre la façon dont l'application a l'air et la façon dont il se comporte, à cause de cela, vous voudrez peut-être examiner le motif MVVM pour séparer ces choses.

Sous le motif MVVM, votre XAML (la vue) contient simplement des liaisons de données très simples dans une vue de vue qui gère tout La logique et met à jour la vue via l'interface INOTIFYPROPERTYANGED. Le code de votre troisième exemple peut ressembler à quelque chose comme: xxx

où FileViewModel est un autre modèle de vue qui contient le nom et l'icône d'un fichier.

L'avantage de cette approche est que les mots de vue peuvent être réutilisés avec d'autres vues et d'autres technologies telles que ASP.NET ou Winforms afin que vous n'ayez pas verrouillé dans la pile WPF. (Alos Si vous travaillez dans un environnement où il y a des concepteurs responsables de l'apparence et des développeurs responsables du comportement, cela aide à définir ces frontières)

à la fin de la journée, bien que cette logique a besoin d'aller quelque part Et bien qu'il existe des moyens meilleurs et pires d'architecte votre application, vous allez toujours écrire du code qui prend une chaîne et la convertit en une série de noms de fichiers et d'icônes quelque part.


2 commentaires

MVVM est la réponse à ce type d'Ails. Logique pour la validation et la transformation de cela sur et que tout va bien dans la fenêtre.


Merci et les autres intervenants aussi! J'ai regardé MVVM lorsque vous commencez et, bien, avez peur de la complexité. Mais votre exemple était vraiment utile pour voir simplement les bases de celui-ci et me convaincant de lui donner un autre. Votre point sur le code qui doit aller quelque part est également bien pris.



5
votes

Premièrement, vous voudrez peut-être commencer par lire sur le modèle de mode-ViewModel ( Mvvm). Josh Smith avait un fantastique article dans le magazine MSDN récemment. MVVM et WPF vont parfaitement ensemble. Fait à droite, vous ne besoin iglueconverters < / code> tellement . La façon dont vous allez à ce sujet est maintenant causant un couplage très étroit entre votre visualisation et vos actions d'application. MVVM est conçu pour découpler ces éléments.

Dans ce contexte, votre modèle de vue suivra votre état pour vous. Votre bouton sera activé si le canexecute méthode sur un certain < Code> ICOMMAND Dans votre modèle, le modèle retourne true. Ce même concept peut gérer le désactivation du bouton lors du traitement de quelque chose.

Vous souhaitez afficher une liste de fichiers dans un certain répertoire spécifié dans une liste de liste? Avoir un DirectoryViewModel Afficher le modèle qui gérera de fournir la liste des fichiers à la vue en reliant le modèle de vue. L'affichage des fichiers peut être spécifié avec un DaTatemplate < / code> spécifié dans xaml sans code derrière. Ce même concept peut gérer de fournir les icônes à la vue dont l'affichage peut être spécifié dans le modèle.

Vous voulez que votre statut soit rouge si un message d'état contient "Erreur" et Green sinon? Soit une vue de modèle de vue de déterminer l'état et laissez la vue se lier à cet état et que vous n'avez maintenant besoin que d'un istateConverter pour convertir l'état en rouge ou vert de manière appropriée (c'est l'une des nombreuses façons de gérer ce problème Dans le contexte MVVM).

Obtention de l'habitude de garder les données et l'état séparé de votre vue et vos applications seront facilement couplées, plus faciles à concevoir et à entretenir, et plus faciles à tester.


0 commentaires

5
votes

Je ne sais pas si vous vous trompez, ce qui en fait beaucoup plus fort qu'il ne doit être!

J'utilise MVVM, alors où vous écrivez des convertisseurs clients, je fournis une propriété contraignante sur le modèle de vue qui raconte la vue quoi faire. Par exemple:

  1. Pour afficher une liste de fichiers, je fournis une collection contenant cette liste.
  2. Si je veux des icônes, l'objet dans cette collection a une propriété icon
  3. Si je veux qu'un statut soit rouge ou vert, je fournis une propriété StatusColorBrush.

    En déplaçant cette logique dans le modèle de vue, je reçois:

    1. beaucoup plus simple xaml.
    2. peut tester ma logique de vue sans vue.

      Cette approche utilise l'un des points forts du WPF, ce sont des capacités contraignantes.


0 commentaires