Implementação de MVP no nível UserControl

Question

Implementação de MVP no nível UserControl

#1 resposta do (3 votos)

5

Estou tentando descobrir como o MVP deve ser implementado no nível UserControl . Eu pensei que tinha, mas acabei lendo um post no blog que praticamente me calou. Agora estou de volta no começo e sem ideia de como proceder.

Digamos que meu UserControl seja algo simples como dois TextBox es e ComboBox . Isso é invocado a partir de um formulário principal (que possui sua própria visualização e apresentador). Agora, a maneira que eu entendo MVP é que o apresentador de formulário principal deve invocar um segundo apresentador para lidar com todas as comunicações com o UserControl que é descartado lá.

E é aí que eu me perco completamente. Minhas implementações passadas de UserControl s (antes de aprender MVP) sempre incorporaram a lógica por trás do controle (por exemplo, ComboBox selection irá mudar o rótulo de texto relacionado a TextBox1 ). Como tal, a implementação do UserControl é feita arrastando-o para o designer e chamando comandos como UserControl1.Update() ou UserControl1.DisplayData(data) .

Em qualquer UserControl de terceiros, todos os comandos para o UserControl são executados por comandos para o controle. Não há nenhum "apresentador" que precise ser chamado, por exemplo, quando eu descartar um controle% WinSeries,% ou ComboBox , ou qualquer outro controle no meu formulário. No entanto, eles têm uma lógica interna que determina como eles são exibidos e, na essência do teste, ele deve ter uma separação de "apresentador" em em algum lugar .

Eu pensei que uma boa solução seria que o construtor do meu ListView criaria um Apresentador. Quaisquer comandos para o UserControl seriam delegados diretamente para o apresentador. Isso permitiria que meu UserControl tivesse sua própria lógica de apresentação separada de sua "visão", de modo que eu possa testá-la e que o implementador (o Formulário Principal) precise apenas descartar UserControl e executar envios de dados e recebe como parte de sua lógica de apresentação local. O UserControl tem sua própria lógica de apresentação deixada invisível para o implementador.

E quando achei que tinha entendido tudo, descobri que é uma prática ruim -Aware View) . Por isso, peço a pessoas que entendem isso melhor do que eu: Como faço para construir um UserControl que mantém sua lógica de apresentação invisível para o usuário final, de modo que não preciso construir o apresentador de wrapping no meu Main Form, < strong> sem violar os princípios que Matt Wynne discute no post relacionado acima?

Ou eu estou completamente entendendo mal o conceito de MVP aqui?

c# user-interface separation-of-concerns mvp winforms

por Arclight 21.08.2013 / 18:09

fonte

1 resposta

Tags c# user-interface separation-of-concerns mvp winforms

Como posso me manter atualizado com o estilo de codificação do Python? Práticas recomendadas para usar sessões HTTP (Java)

score 3 · Answer 1

Eu li a entrada do blog de Matt Wynne que você vinculou, e eu posso ver de onde vem a confusão. Então, vamos apontar algumas diferenças entre o artigo dele e a sua situação.

Sua pergunta foi feita em 21 de agosto de 2013. O artigo de Matt foi publicado em 13 de junho de 2007 .
Você marcou sua pergunta com c # e < href="/ questions / tagged / winforms" class="post-tag" title="mostrar questões marcadas com 'winforms'"> winforms , embora eu ache que você quis dizer wpf ao invés de winForms. Matt afirma que seu foco e experiência foi com o ASP.NET.

Quero salientar que já estamos em um conselho datado eb) diferentes tecnologias de interface do usuário.

O ASP.NET e o (s) padrão (s) MV* que ele suporta mudaram significativamente desde então. Da mesma forma, os usuários do Silverlight e do WPF, desde então, geraram muitas orientações ao usar o padrão MVVM e a vinculação de dados.

E como ponto de referência, eu recomendaria ler os artigos de Martin Fowler sobre Visão passiva e Supervising Controller quais são os padrões que ele criou em seu original Padrão MVP .

Eu acho que a sua pergunta é mais interessante quando se olha para o ponto de vista mais amplo e perguntando "o que o MV* me ajuda em um framework?" E o principal motivador dessa família de padrões é encapsular as áreas que provavelmente mudarão. Relacionado a esse encapsulamento está o princípio da responsabilidade única e certificando-se de que cada componente possui o que deveria.

Nós encapsulamos toda a lógica de exibição na camada View para que possamos alterar mais facilmente nossa tecnologia de interface do usuário em um momento apropriado no futuro. Da mesma forma, com o Model e o que você escolher usar com a camada intermediária.

Portanto, a resposta à sua pergunta é colocar a lógica de visualização apropriada dentro dessa camada para que sua tecnologia funcione. Se você estiver usando winForms, você acabará com muito code-behind para fazer o formulário funcionar. O WPF suporta vinculação de dados e reduz significativamente a quantidade de code-behind. A lógica que você coloca no View deve desaparecer quando você altera as tecnologias da interface do usuário.

Da mesma forma, se você tiver regras de apresentação que não sejam impostas pela tecnologia da interface do usuário, você as colocará na sua camada intermediária à medida que precisarem persistir na próxima interface do usuário.

Não pretendo diminuir o fato de que existem diferenças entre os padrões MV* , e essas diferenças existem por um bom motivo. Mas seu desenvolvimento foi impulsionado pelas necessidades de tecnologias específicas. Você está usando uma tecnologia potencialmente diferente, portanto, use o padrão MV* apropriado para seu ambiente. As estruturas estão aí para facilitar futuras mudanças, não algemar seu desenvolvimento atual.