Para criar uma exibição de aplicativo composto no meu aplicativo, com diferentes regiões, até agora, sempre usei o apresentador de conteúdo e o DataBinding para definir seu conteúdo.

Se eu quisesse alterar seu conteúdo, precisaria usar um agregador de eventos, publicar umViewZoneChangedEvent, inscreva-se na janela "shell" e atualize o modelo de exibição de acordo para que os novos dados fiquem disponíveis para a ligação e a UI seja atualizada.

Agora, eu me deparei recentemente com essas regiões no Prism, na verdade, eu as via há um tempo, mas não me sentia confortável com elas, mas como o Prism é uma espécie de "orientação de melhores práticas", talvez eu esteja perdendo alguma coisa: deixe-me explicar por que me sinto desconfortável.

com a minha maneira antiga de fazer, não há acoplamento com o XAML. você nunca menciona nenhuma sequência mágica específica que deve estar presente no XAML, e acho que isso é essencial, pois o estilo pode mudar.

Se pelo menos as regiões executassem uma verificação em tempo de compilação dos nomes das regiões (verifique se ela realmente existe em algum lugar) que imporia o uso de nomes de regiões válidos e seria muito útil ao refatorar, mas, tanto quanto eu sei, não existe. Algumas pessoas usam enums e osToString método de um enum para convertê-lo em uma string e usá-lo como um nome de região, mas novamente, tanto quanto eu sei, não há uma rotina real para verificar se a string digitada é realmente válida e mostra um erro ao compilar do jeito que está. feito para Brushes.InValidColor, por exemplo.

Portanto, minha pergunta é a seguinte: o que as regiões do prisma trazem para a tabela em comparação com a ligação antiga simples (além do eventAggregator, se você deseja se comunicar através dos modelos de exibição)?

e minhas suposições são verdadeiras sobre a verificação em tempo de compilação dos nomes de regiões?