Besoin de conseils sur la mise en œuvre de l'interface utilisateur dans WPF

Question

J'ai besoin de conseils sur la mise en œuvre des interfaces utilisateur dans WPF. Jusqu'ici, j'ai utilisé Code-Behinds, ce qui est extrêmement facile à démarrer, mais bon quand on le maintient/change/test.

J'ai regardé MVP (et sa variante WPF - MVVM), mais j'ai eu quelques problèmes pour démarrer.

En supposant que j'ai une interface utilisateur de construire, voici ce que je pense que je dois faire:

1. Créer une classe de médiateur « interface principale » qui spécifie toutes les opérations de haut niveau (LoadSettings(), SetVisibility()) et les événements (non déclenchés par l'utilisateur, par exemple, les données de modèle modifiées) que mon interface utilisateur prend en charge.

2. Créer les classes "modèles" pour représenter les données

3. Créer des classes "ViewModel" pour mes classes de modèle. Pour les comportements complexes (par exemple, une séquence d'opérations doit être effectuée avant que l'interface utilisateur puisse/doit mettre à jour, telle que la modification d'éléments dans une collection), ne comptez pas sur ViewModels pour mettre à jour l'interface utilisateur. Au lieu de cela, faites-le manuellement à travers la classe Main Mediator UI.

5. Pour les comportements simples (par exemple, basculement entre les états de visibilité/activé/etc), utilisez la liaison WPF pour lier directement les propriétés de ViewModels à l'interface utilisateur. Dans ce cas, la classe Mediator de l'interface principale maintiendrait les objets ViewModel et Model, et déléguerait les interactions utilisateur (au modèle) et les demandes de mise à jour de l'interface utilisateur (au ViewModel/View) de manière appropriée. La classe Mediator fournit également une interface centralisée qui spécifie les fonctionnalités de l'interface utilisateur, tout en agissant en tant que gestionnaire de changement (décrit dans le modèle d'observateur du GOF) pour gérer le comportement complexe de l'interface utilisateur/réduire les mises à jour redondantes.

Suis-je sur la bonne voie? Devrais-je modifier mon approche? Changer complètement? Pour le moment, je n'ai pas l'expérience/les connaissances nécessaires pour mettre en œuvre des interfaces utilisateur gigantesques/complexes, donc je ne sais pas vraiment si je suis sur la bonne voie.

Merci

Answer 1

C'est un peu long, désolé!

Jusqu'à présent, je me sers de code autotractées, ce qui est extrêmement facile de-commencé, mais l'enfer lors de l'entretien/modification/test.

Yep :) Chaque fois que vous devez nommer un contrôle et d'écrire "dot someControl bla" dans votre code-behind, qui est une odeur de code . C'est parfois inévitable, mais essayez de le limiter autant que possible. Votre interface utilisateur est une projection du modèle - ViewModels et ValueConverters sont un moyen de gérer la non-concordance d'impédance entre les deux domaines.

Quelques problèmes avec votre approche:

Créer une classe de médiateur « interface principale » qui spécifie toutes les opérations de haut niveau

Au lieu de faire cela, vos actes de classe Window comme " Manette"; L'important est, utilisez Commandant pour définir vos actions de premier niveau. De cette façon, UserControls peut être découplé de la classe Window, car UserControl appellera simplement Commands.Open.Execute (null, this), et la fenêtre peut le gérer, et UserControl n'aura jamais de dépendance explicite sur la fenêtre.

Créez des classes "ViewModel" pour mes classes de modèle.

En MVVM, la partie VM est d'aider vous out - si vous pouvez vous contenter de se lier directement au modèle (par exemple les données ne change pas ou ne vous dérange pas la mise en œuvre INotifyPropertyChanged dans vos modèles), puis cela (même si vous devez utiliser quelques classes IValueConverter) est correct. Les ViewModels sont principalement utilisés lorsque la vue est , donc différente de la représentation du modèle qu'il serait moche de pirater votre modèle, ou de "coller" sur des propriétés supplémentaires qui n'ont de sens que dans cette vue particulière.

tout en agissant en tant que gestionnaire de changement ...

Rappelez-vous que WPF fait pour vous, via des propriétés de dépendance et INotifyPropertyChanged; ne réinventez pas la roue; Si vous écrivez une fonction OnDataUpdate(), c'est un signe que vous n'utilisez pas la liaison de données correctement.

par exemple, une séquence d'opérations doivent être faites avant l'interface utilisateur peut/doit mettre à jour, telles que la modification des articles dans une collection

C'est là commandant est grand - votre CanExecute La fonction peut appliquer une logique arbitrairement complexe pour décider si une certaine opération peut être effectuée, et si vous le liez à des éléments d'interface utilisateur tels que Menus ou Boutons, ils seront automatiquement désactivés/activés si nécessaire.

Answer 2

Il n'a pas été mentionné, mais fait tout votre design d'interface utilisateur en XAML.

Il n'y a rien de pire que de voir l'interface utilisateur de WPF être créée par code-behind.