Model View Presenter (MVP) no Android, Parte 1


Os padrões de arquitetura são fundamentais para mantermos um código limpo, expansível e testável. Estas soluções reconhecidas vem sendo desenvolvidas há anos e oferecem referências indispensáveis para a implementação de projetos robustos, com confiabilidade e dentro dos standards que a indústria espera. Neste artigo vamos discutir as principais diferenças entre Model View Presenter (MVP) no Android e MVC, como o modelo MVP se adequa ao Android SDK e as principais vantages deste modelo arquitetônico.

Ao analisarmos o SDK Android, especialmente as relações existentes entre Layout x Activity x Data, temos a impressão que o padrão mais adequado para o ambiente seria o MVC (Model View Controller). Entretanto, quando o projeto começa a ganhar complexidade, o tipo de separação de conceitos oferecido pelo MVC passa a não ser suficiente, especialmente para a criação de testes de unidade.

A forma aberta como o SDK Android foi projetado permite o uso de outros tipo de arquitetura, inclusive a ausência de qualquer padrão, ou os antipadrões como se vê por aí. Embora o MVC seja um padrão sólido e bastante conhecido, ele vem perdendo terreno para seu irmão mais novo, o MVP (Model View Presenter), que oferece algumas vantagens, como uma separação de conceitos mais bem definida.

MVC ou MVP, qual é mais adequado para meu projeto?

Acredito que não há uma resposta certa para esta pergunta. Existem aqueles que defenderão o MVC como solução e outros o MVP e alguns ainda o MVVM. Cada uma destas abordagens têm suas vantagens e desvantagens, além de seus defensores e detratores. A compreensão dos diferentes caminhos a seguir é importante, somente assim você e seu time farão uma escolha mais acertada.

Particularmente, considero que o desenvolvimento no ambiente Android é otimizado com a adoção do Model View Presenter, portanto este é o caminho que sigo nos meus projetos.

Model-view-controller (MVC), em português modelo-visão-controlador, é um padrão de arquitetura de software (design pattern) que separa a representação da informação da interação do usuário com ele. O modelo (model) consiste nos dados da aplicação, regras de negócios, lógica e funções. Uma visão (view) pode ser qualquer saída de representação dos dados, como uma tabela ou um diagrama. É possível ter várias visões do mesmo dado, como um gráfico de barras para gerenciamento e uma visão tabular para contadores. O controlador (controller) faz a mediação da entrada, convertendo-a em comandos para o modelo ou visão. As ideias centrais por trás do MVC são a reusabilidade de código e separação de conceitos.
Retirado do Verbete Wikipedia
Model–view–presenter (MVP) é uma derivação do padrão de software model-view-controller (MVC), usado também para construir principalmente interfaces gráficas.
Em MVP a camada
Presenter assume a função de mediadora (executada pelo Controller em MVC). Além disso, a View é responsável por manipular os eventos UI (como mouseDown, keyDown, etc.), que era o trabalho da Controller. Finalmente, a Model se torna estritamente um modelo de domínio.
Retirado do Verbete Wikipedia
MVC vs MVP

Principais diferenças

Model View Presenter

  • View mais separada do Modelo. O Presenter faz a mediação entre o Modelo e View.
  • Mais fácil de fazer unidades de teste.
  • Geralmente há um mapeamento de um a um entre View e Presenter, com a possibilidade de presenters múltiplos para views complexos.

Model View Controller

  • Controllers são baseados em comportamento e podem ser compartilhados entre múltiplas views.
  • View pode se comunicar diretamente com os modelos

Model View Presenter (MVP) no Android

No Android a separação de conceitos não é naturalmente bem definida. As Activityes tem uma relação muito próxima com os mecanismos de acesso de dados. Para uma aplicação ser fácil de expandir, manter e testar, precisamos criar clara separação entre conceitos. Este é o principal vantagem conseguida com a implementação do MVP no Android.

Separação de conceitos MVP no android

Como implementar?

Este ponto é meio vago. Há muitas divergências sobre a melhor maneira de implementar o Model View Presenter e como adapta-lo ao ambiente Android. O padrão varia basicamente de acordo com a quantidade de responsabilidades que o Presenter assume. De uma maneira ou de outra, o cerne do MVP não é alterado:

Presenter

O presenter age como intermediário entre a view e o model. Ele retira os dados do modelo e retorna para a view. Mas, diferente de típicos MVC, ele também decide o que acontece quando usuário interage com a view.

View

O view, normalmente implementado por uma Atividade (também pode ser um Fragmento ou qualquer elemento UI, dependendo da estrutura do aplicativo), vai conter uma referência para o presenter. O presenter pode ser criado pela Activity ou fornecido via injeção de dependência. A única responsabilidade da View é chamar métodos no Presenter toda vez que o usuário interage com ela.

Model

O model é responsável pelos dados que serão exibidos na interface do usuário. Poderíamos considerar como modelo, além dos dados, qualquer lógica de manipulação e acesso destes dados.
As definições acima foram extraídas em livre interpretação do excelente artigo de Antonio Leiva.

Há bastante discussão sobre qual seria a forma ideal de implementar o padrão Model View Presenter no Android. Como não existe uma fórmula “correta”, ficará ao teu critério qual caminho escolher. Independente da abordagem adotada, o cerne da arquitetura MVP deve ser preservado.

No próximo artigo da série implementaremos o padrão Model View Presenter no Android. Utilizaremos uma alternativa bastante canônica, que não faz uso de qualquer library ou injeção de dependências, para assim compreendermos melhor os conceitos envolvidos no processo. Nossa reflexão será baseada na proposta do Dr. Douglas C. Schmidt, professor da Universidade Vanderbilt.

Se você pretende começar logo a testar e conhecer mais sobre o MVP, existem alguns bons frameworks e librarys que auxiliam na implementação do padrão no Android. Uma excelente alternativa é o Mosby, que possui uma documentação fora do comum (toda em inglês). Antonio Leiva também mantém um repositório git com um bom exemplo de implementação.

Até a próxima!

Referências: