MVVM x MVP
Quando comecei a estudar sobre arquiteturas, principalmente no contexto de mobile, me deparei principalmente com duas siglas que, de início, deram um nó no meu cérebro: MVVM e MVP.
Confesso que ainda não tive a oportunidade de trabalhar diretamente com MVP, mas eu queria entender o porque muitas empresas escolhiam utilizá-la, visto que o MVVM é recomendado pela própria Google.
E depois desse breve estudo, apesar de MVVM continuar sendo meu queridinho (ainda mais combinado com Clean Architecture), resolvi trazer as diferenças que notei entre eles para que você, de forma bem sucinta, seja capaz de definir o que é melhor a depender do seu contexto/escopo.
MVVM
É a famosa Model-View-ViewModel. É uma arquitetura que se popularizou principalmente pela sua separação clara de atribuições.
Model: É basicamente a abstração dos seus objetos, que encapsulam seus dados. É esta camada que, por exemplo, representará seu Response de uma chamada. A nossa viewModel é capaz tanto de receber Models, quanto de enviar Models. Nesta camada também ficam suas regras de negócio.
View: É a sua camada de apresentação, seja ela uma Activity, Fragment, etc. Ela conterá uma referência direta para a sua viewModel no intuito de captar os dados que você processou.
ViewModel: É quem, de fato, conterá as suas regras de apresentação. É onde você, muito provavelmente, colocará todos os seus "IF's" e loopings. É também a camada responsável de notificar a sua view após a alteração de algum dado/estado. Essa notificação pode ser feita de algumas maneiras, e essas maneiras merecem um artigo específica delas.
Lembre-se:
Sua viewModel, de forma alguma, deverá ter referências da sua view. Se isso acontecer em algum momento, a sua arquitetura precisa ser revista.
O que eu acho mais bacana da arquitetura MVVM, além da sua clareza nas responsabilidades de cada camada, é a reutilização de código, basicamente. Ou seja, uma única viewModel pode ser referenciada por múltiplas views. Mas cuidado ao utilizar esse recurso para não sobrecarregar sua viewModel. Por exemplo, se reparar que dois Fragments, apesar de pertencerem ao mesmo contexto, diferem muito na lógica e possuem muitos cenários específicos, vale a pena fazer uma viewModel para cada uma delas.
Lembre-se sempre de aplicar um dos princípios de SOLID: O princípio de responsabilidade única.
MVP
É uma arquitetura também amplamente utilizada e que, no lugar da nossa conhecida viewModel, entra um carinha chamado Presenter.
É só isso que muda? Obviamente não! A forma como as camadas se comunicam também difere da MVVM. Mas antes, vamos entender cada letra:
Model: É basicamente o mesmo carinha da MVVM. É quem representará de fato o seu objeto e que conterá a sua lógica de negócio. Sem segredos, certo?
View: É a sua camada de UI, assim como no MVVM. Podendo ser uma activity, uma fragment, etc.
Presenter: É aqui que começamos a diferenciar as arquiteturas. O Presenter é como um mediador entre as camadas. Ou seja, ele pega os dados da view (por exemplo, os dados digitados pelo usuário) e entrega para a Model realizar o tratamento. Também pega os dados da camada de Model e entrega para a view. Deu para sacar a diferença entre um Presenter e uma ViewModel? Se não, vamos prosseguir que explicarei.
E afinal, quais as diferenças?
Para quem está iniciando nesse mundo de arquiteturas, pode pensar a princípio, que tratam-se apenas de denominações diferentes. Mas a realidade é que MVP é o oposto de MVVM. Vamos elencar as principais diferenças:
- MVVM trata-se de uma arquitetura orientada a eventos. Ou seja, ela dispara eventos para que a View seja notificada. Enquanto o MVP funciona mais como uma "ponte" de comunicação entre a View e a Model. Este tipo de diferença pode ser notada claramento pelo simples fato de que, em MVVM, a viewModel não conhece (e nunca deve) a sua view. Enquanto em MVP, a camada de Presenter conhece tanto a camada Model, quanto a View.
- Enquanto no MVVM a relação pode ser múltipla entre views e viewModel, na arquitetura MVP a relação é 1 para 1. Ou seja, um Presenter pode se referenciar somente a uma view.
- O fato de MVP possuir relação 1 para um favorece para um código altamente acoplado. Ou seja, digamos que tenhamos que alterar a view, teremos também que alterar todo o relacionamento (entre view, Presenter e Model). Enquanto na arquitetura MVVM esse tipo de relação é mais abstraído, já que a viewModel expõe somente os dados/estados mas não tem ideia de como/quem vai consumir.
Se estes motivos acima já não fossem o suficiente, ainda temos o quesito de testabilidade. Pelo fato do relacionamento em MVP ser 1 para 1, é muito difícil testar suas classes unitariamente, já que em um simples teste de Presenter, por exemplo, seria necessário expor sua view também.
Como dito anteriormente, a Google já assumiu por padrão a arquitetura MVVM, mas é importante que a gente conheça sobre as demais possibilidades para que possamos tomar decisões arquiteturais com propriedade e não somente por "modismo" e/ou recomendações de boas práticas. Afinal, se é recomendado, algum motivo tem. E se tem, por que não conhecê-lo? ;)
Lembrando aqui que o intuito desse artigo não é me aprofundar na usabilidade de cada uma das arquiteturas, mas sim, trazer um breve resumo e as principais diferenças entre elas.
Code Like a Girl 👧
