Um in meiner Anwendung eine Verbundanwendungsansicht mit verschiedenen Regionen zu erstellen, habe ich bisher immer Content Presenter und DataBinding zum Festlegen des Inhalts verwendet.

Wenn ich den Inhalt ändern wollte, musste ich nur einen Ereignisaggregator verwenden, ein @ veröffentliche ViewZoneChangedEvent, abonnieren Sie es im "Shell" -Fenster und aktualisieren Sie das Ansichtsmodell entsprechend, sodass die neuen Daten für die Bindung verfügbar sind und die Benutzeroberfläche aktualisiert wird.

Nun bin ich kürzlich auf diese Regionen in Prism gestoßen. Eigentlich hatte ich sie eine Weile gesehen, aber ich fühlte mich nicht wohl damit, aber da Prism eine Art "Best Practices-Anleitung" ist, fehlt mir vielleicht etwas: Lassen Sie mich erkläre, warum ich mich unwohl fühle.

mit meiner alten Art zu tun, gibt es keine Kopplung mit der XAML. Sie erwähnen niemals eine bestimmte magische Zeichenfolge, die in der XAML vorhanden sein sollte, und ich denke, das ist wesentlich, da sich der Stil ändern kann.

Wenn zumindest die Regionen eine Überprüfung der Regionsnamen zur Kompilierungszeit durchführen würden (stellen Sie sicher, dass sie tatsächlich irgendwo vorhanden sind), würde dies die Verwendung gültiger Regionsnamen erzwingen und beim Refactoring sehr hilfreich sein, aber soweit ich weiß, gibt es so etwas nicht. Einige Leute benutzen Aufzählungen und dasToString -Methode einer Aufzählung, um sie in eine Zeichenfolge umzuwandeln und als Regionsname zu verwenden, aber meines Wissens gibt es keine echte Routine, um zu überprüfen, ob die eingegebene Zeichenfolge wirklich gültig ist, und einen Fehler beim Kompilieren anzuzeigen wird zum Beispiel für Brushes.InValidColor ausgeführt.

Also lautet meine Frage wie folgt: Was bringen die Prismenregionen im Vergleich zur normalen alten Bindung (plus eventAggregator, wenn Sie über ViewModels hinweg kommunizieren möchten) auf den Tisch?

und stimmen meine Annahmen über die Überprüfung der Regionsnamen während der Kompilierung?