Os aplicativos devem ser arquitetados para o uso correto do evento PropertyChanged, atendendo aos seguintes requisitos:
Sempre disparar um evento PropertyChanged para quaisquer propriedades calculadas cujos valores sejam usados por outras propriedades no Model ou ViewModel.
Sempre disparar um evento PropertyChanged no final do método que faz uma alteração de propriedade, ou quando se sabe que o objeto está em um estado seguro. Gerar o evento interrompe a operação invocando os manipuladores do evento de forma síncrona. Se isso acontecer no meio de uma operação, poderá expor o objeto a funções de retorno de chamada quando estiver em um estado não seguro e parcialmente atualizado. Além disso, é possível que mudanças em cascata sejam acionadas por eventos PropertyChanged. As alterações em cascata geralmente exigem que as atualizações sejam concluídas antes que a alteração em cascata seja segura para execução.
Nunca disparar um evento PropertyChanged se a propriedade não for alterada. Isso significa que você deve comparar os valores antigos e novos antes de gerar o evento PropertyChanged.
Nunca disparar um evento PropertyChanged durante o construtor de um ViewModel se você estiver inicializando uma propriedade. Os controles vinculados a dados na View não estarão assinados para receber notificações de alteração neste momento.
Nunca disparar mais de um evento PropertyChanged com o mesmo argumento de nome de propriedade em uma única invocação síncrona de um método público de uma classe. Por exemplo, dada uma propriedade NumberOfItems cujo armazenamento de apoio é o campo _numberOfItems, se um método incrementa o _numberOfItems cinquenta vezes durante a execução de um loop, ele só deve gerar notificação de alteração de na propriedade NumberOfItems uma vez, depois que todo o trabalho estiver concluído. Para métodos assíncronos, gere o evento PropertyChanged para um determinado nome de propriedade em cada segmento síncrono de uma cadeia de continuação assíncrona.
