Vamos explorar o potencial do padrão MVP para implementar duas interfaces com a mesma camada de apresentação.
O padrão MVP separa a camada de interface da aplicação (UI) em outras duas camadas.
- Apresentação (Presenter)
Cama responsável pela lógica de apresentação. - Interface do Usuário (View)
Contem apenas os controles de interface com o usuário.
Esta separação que nos permite implementar duas interfaces, Forms e Web, com a mesma lógica de apresentação sem tem que criar duas aplicações diferentes que fazem a mesma coisa.
Diagrama do padrão MVP
O segredo é que a camada de apresentação (Presenter) não precisa saber com qual interface (View) estamos lidando, seja ela Froms ou Web, só precisa saber que ela implementa uma interface (IView) que ela já conhece.
Implementando
Nosso cenário será o cadastro de uma conta (Account) em uma aplicação onde cada conta está associada a uma corretora (Brokerage).
Entidades de Neócio
- Account
- Brokerage
Nosso presenter (AccountPresenter) será o responsável por gerenciar os elementos da interface que informarão o número, nome e a corretora da conta, independente da interface que está sendo usada para o input dos dados. O pesenter só saberá que esta interface com o usuário implementa a interface IAccountView.
O persenter é o responsável apenas pela lógica de apresentação da view, então nós usaremos um controlador (Controller) para solicitar a lista de corretoras disponíveis para nossa conta e também persistir nossos dados. O controller e a persistência dos dados estão fora do escopo deste post, então só precisamos saber que eles existem e em outra oportunidade falaremos mais sobre eles.
O presenter deve ler da view o número, nome da conta e qual corretora o usuário escolheu da lista de corretoras informadas pelo controller. Aqui temos duas questões muito importantes sobre como a view vai mostrar para o usuário uma lista de corretoras disponíveis sem conhecer minha entidade Brokerage e como meu presenter vai saber qual corretora o usuário escolheu se ele não sabe qual view, Forms ou Web, nem qual controle está sendo usado para fazer a escolha.
Este problema nós só resolvermos utilizando um outro padrão descrito pela Gang dos Quatro (GoF) chamado Adapter. Para isso, o presenter só saberá que o controle da view responsável por listar as corretoras e informar qual foi a escolhida implementa a interface IListControl e um adapter para o controle da interface fará a implementação desta interface no controle. Assim conseguiremos manter o desacoplamento entre as camadas.
Adaptando um controle web
Na web podemos criar um adapter único para os controles DropDownLits, ListBox porque os dois controles herdam a classe ListControl, então nosso adapter receberá um controle que herde de ListControl e implementará a interface IListControl que nosso presenter já conhece.
Adaptando um controle Windows Forms
Nos controles windows forms as coisas não foram tão simples porque apesar do ComboBox e o ListBox herdarem da classe ListControl ela não nos disponibiliza a coleção dos itens que populam o controle, nos forçando a criar um adapter para o controle ComboBox e outro para o ListBox.
Com isso tudo na cabeça chegou a hora de ver se isso funciona mesmo!
Baixe o projeto de exemplo, debug e veja isso tudo funcionando.
Download
