MVVM - janelas filho e contextos de dados

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.

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.

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.