MVP (Controlador de supervisão) A exibição atualiza o modelo?

Eu tenho lido sobre MVP, especificamente Supervisionando Controller. Uma coisa que estou tendo dificuldade em entender é como o View interage com o Modelo.

Entendi que o apresentador deveria atualizar o modelo e que o View lê do modelo. O Presenter também pode atualizar a exibição por meio de uma interface. O artigo de Martin Fowler sobre isso parece mostrar exatamente isso ( http://martinfowler.com/eaaDev/SupervisingPresenter.html ).

No entanto, outros artigos / blogs mostram a visualização atualizando o modelo diretamente ( https://blogs.msdn.microsoft.com/erwinvandervalk/2009/08/14/the-difference-between-model-view-viewmodel-and-other- padrões de apresentação separados / ).

Sei que esses são apenas padrões, portanto, haverá implementações diferentes, mas a exibição da atualização do modelo parece estar fazendo muito mais do que deveria.

Digamos, por exemplo, eu tive uma classe de pessoa que continha um nome e número de telefone. A visualização pode exibir esse nome e número e um botão de envio para alterar o nome e o número da pessoa. Quando o botão enviar é clicado, eu esperaria que a atualização fosse realizada no Presenter e não na View. No entanto, o artigo que referi propõe que a visualização pode atualizar diretamente o modelo.

Então, a visualização deve sempre atualizar o modelo? Ou isso deve ser tratado apenas pelo apresentador?

EDITAR:

Código do artigo do MSDN:

public class PersonalDataView : UserControl, IPersonalDataView
{
    protected TextBox _firstNameTextBox;

    public void SetPersonalData(PersonalData data)
    {
        _firstNameTextBox.Value = data.FirstName;
    }

    public void UpdatePersonalData(PersonalData data)
    {
        data.FirstName = _firstNameTextBox.Value;
    }
}

Existem várias variantes do MVP desde o seu design original em 1996 por Mike Potel . Martin Fowler discute alguns deles em outro artigo sobre arquitetura de GUI .

Uma das principais diferenças entre as variantes é se a visualização é totalmente isolada do modelo ou não:

• No primeiro caso, o apresentador é o homem no meio de uma "visão passiva" e o modelo.
• No segundo caso, o apresentador é um "controlador supervisor", mas há interações diretamente entre a visualização e o modelo. O artigo de Potel descreve bem o tipo de interação: a visualização pode solicitar dados do modelo e o modelo pode notificar a visualização de alguns eventos.

Em nenhum dos casos, a visualização alteraria diretamente o modelo. A mudança do modelo ocorre sempre através do Presenter (ou do controlador em um MVC).

Observação 1: O artigo do MSDN mostra apenas uma seta diretamente da exibição para o modelo, em sua introdução na parte MVC (Model View Controller). A seta está na direção errada, mas o texto está correto: a visualização pode acessar o modelo e mudar a si mesma (ou seja, não o modelo, mas redesenhar a si mesma) após a alteração dos dados do modelo.

Observação 2: O artigo do MSDN também mostra o padrão MVVM da Microsoft, que é aproximadamente um MVP, mas o apresentador é ambiguamente chamado de "ViewModel". Porém, novamente, a Visualização não atualiza o modelo diretamente.

Sua edição:

O código da sua edição mostra uma ligação de dados bidirecional, em que a atualização de dados na exibição acionaria diretamente uma alteração no modelo. Isso de fato contradiz o padrão original do MVP, no qual a View informa o apresentador das alterações desejadas por meio de um "Interator" e o Presenter tem o monopólio de invocar "Commands" para atualizar o modelo.

Observação 3: acho que o autor deste blog do MSDN estava mais interessado em introduzir a arquitetura MVVM do que em escrever um artigo abrangente e abrangente, como Martin Fowler, sobre as demais arquiteturas. Penso também que a arquitetura de ligação de dados ADO da Microsoft, que remonta aos primeiros dias da estrutura .net, favorecia um design misto e tornava um MVP clássico menos trivial de implementar (era necessário um DataObjectSource para isolar o acesso ao modelo de dados).

No artigo Fowler's Supervising Presenter, que você vinculou na sua pergunta:

Fatore a interface do usuário em uma visualização e controlador em que a visualização manipule mapeamento simples para o modelo subjacente e o controlador manipule a resposta de entrada e a lógica complexa da visualização.

Diz claramente que, para todas as tarefas simples, a visualização pode falar diretamente com o modelo. Portanto, isso não contradiz o artigo do MSDN. Isso ocorre exatamente porque, para mapeamento / associação simples de propriedades, você não precisa envolver outra camada, pois isso apenas complicaria as coisas sem muitos benefícios.

Novamente, Fowler fala sobre isso no final do artigo:

[...] a questão motriz é a quantidade de comportamento que resta na exibição. A Visão Passiva é um padrão muito semelhante ao Supervisão de Controlador, mas com a diferença de que a Visão Passiva coloca todo o comportamento de atualização da visão no controlador, incluindo casos simples. Isso resulta em programação extra, mas significa que todo o comportamento da apresentação é testável. A escolha entre os dois depende de que tipo de suporte de Ligação de Dados você possui e se está feliz em deixar isso não testado pelos testes do controlador.

Você deve ter em mente algumas coisas:

• Certifique-se de que o modelo seja o "mestre" dos dados a qualquer momento. Isso significa que o View nunca deve gravar diretamente nos campos do modelo (de qualquer maneira, é uma má ideia). Propriedades está ok se o seu idioma as suportar. Dessa forma, o modelo ainda pode reagir a qualquer atualização de seus dados (por exemplo, calculando outro campo).
• Não combine seu modelo com a vista. O modelo deve ser testado independentemente e, em princípio, você poderá alterar a visualização sem afetar o modelo. Isso significa que o modelo nunca deve chamar diretamente a visualização. Use interfaces, ou provavelmente o melhor aqui, o padrão Observer. O View pode se inscrever no modelo para atualizações.
• Nunca coloque nenhuma lógica (comercial) na exibição. Se você se encontra escrevendo ifinstruções no código de exibição, pense se essas devem pertencer ao apresentador ou modelo.