Prisme, régions, cordes magiques et refactoring: ai-je oublié quelque chose ici?

Question

Pour créer une vue d'application composite dans mon application, avec différentes régions, jusqu'à présent, j'ai toujours utilisé le présentateur de contenu et DataBinding utilisé pour définir son contenu.

Si je voulais changer son contenu, je voudrais juste avoir à utiliser un agrégateur d'événements, publier un ViewZoneChangedEvent, abonnez-vous à elle dans la fenêtre « shell », et mettre à jour le viewmodel en conséquence afin que les nouvelles données seraient disponible pour la liaison et l'interface utilisateur être mis à jour.

Maintenant, je suis récemment tombé sur ces régions dans Prism, en fait je les avais vues depuis un moment mais je ne me sentais pas à l'aise avec elles, mais depuis Prism est un guide des meilleures pratiques : Laissez-moi vous expliquer pourquoi je me sens mal à l'aise. Avec ma vieille façon de faire, il n'y a pas de couplage avec le XAML. vous ne mentionnez jamais de chaîne magique spécifique qui devrait être présente dans le XAML, et je pense que c'est essentiel, puisque le style peut changer. Si au moins les régions effectuent une vérification à la compilation des noms de régions (vérifiez qu'il existe réellement quelque part) qui s'appliquerait en utilisant des noms de régions valides et serait très utile lors du refactoring, mais pour autant que je sache, il n'y a pas telle chose. Certaines personnes utilisent enums et la méthode ToString d'une énumération pour la convertir en chaîne et l'utiliser comme un nom de région, mais là encore, pour autant que je sache, il n'y a pas de routine pour vérifier si la chaîne tapée est valide erreur lors de la compilation de la façon dont il est fait pour Brushes.InValidColor par exemple. Donc, ma question est la suivante: qu'est-ce que les régions de prisme apportent à la table par rapport à la vieille liaison (plus eventAggregator si vous souhaitez communiquer à travers ViewModels)?

et mes hypothèses sont-elles vraies au sujet de la vérification de compilation des noms de région?

Answer 1

Il est beaucoup plus propre d'utiliser des régions que de le faire "à la main". En utilisant des régions, vous n'avez besoin d'aucune connaissance sur la façon dont vous devez ajouter de nouvelles vues au parent composite. Si vous le faites "à la main", vous devez ajouter du code-behind dans votre vue, ce qui est une mauvaise chose.

La façon dont j'évite les cordes magiques est de définir tous les noms de région constantes

public class RegionNames 
{ 
    public static string MainRegion { get { return "MainRegion"; } } 
} 

puis définissez la région comme une ressource ainsi (dans le App.xaml par exemple)

<Application.Resources> 
    <ResourceDictionary> 
     <infrastructure:RegionNames 
      xmlns:infrastructure="clr-namespace:MyClass.Silverlight;assembly=MyModule.Silverlight" 
      x:Key="RegionNames" /> 
    </ResourceDictionary> 
</Application.Resources> 

Ensuite, j'ajoute des noms de régions spécifiques au module en tant que constantes au niveau du module.

Il n'y a malheureusement pas de vérification à la compilation, mais c'est beaucoup mieux et plus propre que d'ajouter les noms de régions directement dans le XAML, surtout si vous réutilisez le nom dans le code plus tard.

EDIT: J'ai oublié d'inclure le code XAML pour montrer comment vous utilisez cette constante. Ceci est maintenant corrigé.

Quelque part au sommet du XAML, comprennent la référence au gestionnaire de la région:

xmlns:Regions="clr-namespace:Microsoft.Practices.Composite.Presentation.Regions;assembly=Microsoft.Practices.Composite.Presentation" 

Et puis lors de la mise en place de la région d'utiliser le nom de la région définie comme la ressource

<ItemsControl Regions:RegionManager.RegionName="{Binding MainRegion, Source={StaticResource RegionNames}}" /> 

Answer 2

Ma compréhension des régions est qu'elles vous permettent d'exécuter plusieurs modules PRISM en même temps s'ils s'exécutent chacun dans une région différente. Exemple: la région principale peut être remplie avec un module d'entrée de données tandis qu'une région d'en-tête peut être remplie avec une région de messagerie/alerte de l'utilisateur.