Loose Coupling Presenter para visualizar no MVP

5

Trabalhamos em uma loja Java aqui e nosso aplicativo da web usa uma implementação do Padrão arquitetural MVP . Nosso gerente vem de um mundo .NET, onde ele foi exposto ao padrão de design MVVM . Nosso gerente está defendendo mudanças em nossa implementação de MVP, incluindo que os apresentadores devem ser dissociados de (ou fracamente acoplados a, dependendo de sua interpretação) suas Views através do padrão de projeto Observer, na tradição com o MVVM. Eu sou mais da opinião de que o Apresentador e a Visão trabalham juntos para alcançar um objetivo comum e, como tal, devem ser acoplados.

Entre os argumentos apresentados em apoio à mudança está a capacidade de apresentar os apresentadores de teste da unidade. Se os apresentadores só vêem as visualizações como observadores, o argumento continua, então eles podem ser mais facilmente testados na unidade. Mas os apresentadores strongmente ligados a seus pontos de vista não são necessariamente difíceis de testar. Se o modo de exibição usar o paradigma Humble View , ele poderá ser ridicularizado. E, finalmente, testabilidade deve ser um sintoma de bom design, não um driver para o design.

Outro argumento usado pelo meu gerente para apoiar a disposição em camadas das Views e dos Presenters é a suposta maturidade do MVVM. Como tal, devemos seguir os ensinamentos do MVVM e nos adaptar à sua implementação do MVP. Corrija-me se estiver errado, mas o MVVM impõe a camada (artificial) de visualizações e apresentadores para facilitar suas ligações de dados nos controles.

Você pode nos ajudar a ver a luz aqui? Por que devemos usar um modelo desacoplado e pagar o preço por isso? Eu não estou vendo o benefício. A navalha de Occam diz que eu preciso de argumentos para usar o desacoplamento, e o teste não parece ser um deles.

Esclarecimento : O que eu realmente estou procurando com essa questão são os argumentos que podem inclinar a balança em favor de um apresentador que não sabe sobre sua visão e filma eventos no éter ou em favor de um apresentador que conheça a (s) sua (s) visão (ões) através de um acoplamento mais direto, como uma interface de visualização humilde ou diretamente para a classe. Observe que os apresentadores podem facilmente exibir várias visualizações com acoplamentos frouxos e apertados. A diferença está na interface com a qual o apresentador fala: com o acoplamento solto, o apresentador fala com as classes ouvintes (ou um representante do barramento de eventos), enquanto que, com um acoplamento apertado, o apresentador fala com a interface da exibição.

    
por Mihai Danila 16.01.2014 / 20:29
fonte

1 resposta

-1

Peço desculpas para ser o único a derrubar o argumento contra você. Você está certo, uma das vantagens do MVVM é sua capacidade (se implementada corretamente) de não precisar sincronizar manualmente seus dados.

Eu também teria que concordar com o teste ser mais fácil com o MVVM.

Para mais argumentos contra ou para, eu teria que dizer que outra força do MVVM é que você pode ter mais de um View Model para múltiplas Views.

Portanto, as três principais razões para o MVVM em relação ao MVP eu teria que dizer são:

  1. Ligação de dados
  2. Teste
  3. Múltiplas visualizações podem usar mais de um modelo de exibição - significa que você não precisa criar um apresentador para todas as visualizações.

Depois disso, os benefícios se tornam menores, e eu sinto que a comodidade no design que você está usando iria pesar esses benefícios. No entanto, é bom esticar e espalhar-se em áreas desconfortáveis de design e programação, ampliando seus horizontes.

    
por 22.04.2014 / 05:51
fonte