MVVM - janelas filho e contextos de dados

5

Uma janela filho deve ter seu próprio contexto de dados (View-Model) ou usar o contexto de dados do pai? Mais amplamente, cada View deve ter seu próprio View-Model? Existem regras para orientar essa decisão? E se os vários modelos de visualização estiverem acessando o mesmo modelo?

Não consegui encontrar nenhuma orientação consistente sobre a minha pergunta. A definição de MS do MVVM parece ser silenciosa em janelas filho.

Por exemplo, criei uma visualização de notificação de mensagem de aviso. Realmente não precisou de um contexto de dados desde que foi passado a mensagem para exibir. Mas se eu precisasse imaginar um pouco, eu teria aproveitado o contexto de dados dos pais.

Corri para outro cenário que precisa de uma janela filho e é mais complicado que a caixa de notificação. O View-Model do pai já está ficando confuso, então planejei gerar uma VM dedicada para a janela filho. Mas não consigo encontrar nenhuma orientação sobre se isso é uma boa ideia ou quais as possíveis conseqüências.

FWIW, por acaso estou trabalhando no Silverlight, mas não sei se essa questão é estritamente um problema do Silverlight.

    
por GlenH7 10.09.2012 / 23:44
fonte

3 respostas

4

Eu acho que depende. No projeto em que estou trabalhando atualmente, usamos as duas abordagens. Eu suponho que se resume a como a funcionalidade da janela filho é relacionada ao pai. Se a nova janela for na maior parte suplementar, como um prompt ou uma pequena caixa de diálogo de entrada, simplesmente usei o contexto de dados do pai, porque os dados fornecidos por esse diálogo ainda eram muito relevantes para a funcionalidade do pai. Por outro lado, se a nova janela for um recurso significativo em si, pode ser mais apropriado usar um novo contexto de dados que retorne ao pai (se aplicável). Pense nisso desta maneira, quando projetar uma classe, quando é apropriado dividir a funcionalidade em outra classe? Você não precisa necessariamente de um modelo de visão difícil de lidar com um monte de funcionalidades não relacionadas reunidas. Infelizmente, isso se transformou em uma resposta bastante confusa que depende do seu melhor julgamento.

    
por 11.09.2012 / 00:00
fonte
1

A regra que eu usaria é um ViewModel por View. Se é algo muito genérico, é um controle e não uma visão específica. Nesse caso, usaria DataContext do pai View. Os avisos do MessageBox também podem ser exibidos usando algum tipo de classe de serviço que você injetaria no ViewModels. O ViewModels também pode ter outros ViewModels aninhados neles, por exemplo, quando você está usando controles do tipo Grid.

    
por 11.09.2012 / 10:17
fonte
1

Eu sinto que qualquer visão infantil deve ter seu próprio modelo de visualização. Digo isso porque, se você removesse a visualização filho da visualização pai, teria dados redundantes (que eram destinados à exibição secundária) no modelo de exibição pai. Parece-me que, por esse motivo, faria mais sentido ter um modelo de visão para cada um.

    
por 11.09.2012 / 12:02
fonte

Tags