View
6
Download
0
Category
Preview:
Citation preview
1
April 08 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 1
Módulo II Modelo MVP
Prof. Ismael H F Santos
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 2
Referências (livros)
2
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 3
Referências (na Web)
GUI Architectureshttp://martinfowler.com/eaaDev/uiArchs.html
Channel9http://channel9.msdn.com/ShowPost.aspx?PostID=313257
Microsoft sobre MVPhttp://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx
MVChttp://en.wikipedia.org/wiki/Model-view-controller
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 4
Referências (na Web)
Passive Viewhttp://www.martinfowler.com/eaaDev/PassiveScreen.html
Supervising Controller (Supervising Presenter?)http://www.martinfowler.com/eaaDev/SupervisingPresenter.html
GUI Architectureshttp://martinfowler.com/eaaDev/uiArchs.html
Podcastshttp://polymorphicpodcast.com/shows/mv-patterns/
Stub Generator (mais curiosidade do que realidade...)http://www.polymorphicpodcast.com/tools/mvp-stub/
3
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 5
Modelos Camada de
Apresentação
FPSW-Java
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 6
Introdução
Os padrões tem a ver com a separação (ou falta dela) entre dois tipos de lógica:
Lógica da apresentação (presentation logic) consiste em lógica para apresentar o resultado de um processamento.Lógica do negócio (business logic) consiste em lógica para produzir os resultados desejados.
Cada um desses dois tipos possui uma grupo de responsabilidades distintas...
4
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 7
IntroduçãoResponsabilidades da lógica do negócio
Validações de regras de negócio,Manutenção das informações do sistema.
Responsabilidades da lógica da apresentaçãoDisposição (Layout),Animação e desenho (rendering),Criação dinâmica de uma visão (e.g., menus suspensos),Visibilidade/invisibilidade progressivas,Validação dos dados de entrada,Formatação da saída (e.g., formatos para datas),Localização/Internacionalização.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 8
Padrões de softwareAutonomous ViewModel View ControllerModel View Presenter
Supervising Presenter (ou Supervising Controller)Passive ViewPresentation Model
View Helper
5
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 9
Autonomous View
Os desenvolvedores desenham os formulários da aplicação que usam controles gráficos genéricos.O formulário descreve a disposição dos controles nele.O formulário observa os controles e tem os métodos manipuladores para reagir aos eventos interessantes originados nos controles.A edição simples de dados é realizada com a estratégia “Data Binding”.Alterações complexas são feitas pelos métodos manipuladores de eventos do formulário.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 10
Autonomous View
CaracterísticasO estado da apresentação está no ViewA lógica da apresentação está no View
Em casos extremos (piores?), a lógica do negócio e a interação com serviços remotos também é posicionada no View.
Na verdade, isso é um Anti-Pattern chamado Smart UI.Mas é possível usar um Autonomous View que faça essa extração para outras classes.
6
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 11
Autonomous View
Vantagem:Simplicidade na implementação.
DesvantagensDifícil de aplicar testes unitários (unit testing),Separação de responsabilidades (separation ofconcerns) não é adequada,Duplicação de código entre diferentes Views.
Os padrões descritos a seguir tentam remover essas desvantagens do padrão Autonomous View.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 12
Padrão utilizado para separar a lógica da apresentaçãoda apresentação propriamente dita.A idéia básica é que toda a lógica que normalmente iria ligar a IU com os dados seja movida para uma classe separada.Resultado: a IU (Forms, UserControls, etc) é burra.
A IU é “burra” no sentido de que não há processamento embutido nela.
Existe em inúmeras variantes (e sub-variantes!).
MVC (Model View Controller)
7
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 13
MVC (Model View Controller)
Um arquitetura de desenho comumente utilizada para aplicações com interface gráfica.Inicialmente desenvolvido para a linguagem SmalltalkQuando uma aplicação gráfica usa um objeto, este objeto pode ser visto como um modelo.O modelo provê operações para que o restante da aplicação possa manipulá-lo.Uma aplicação pode conter diversão visões de um modelo.
e.g.: visões de edição, impressão e de seleção de um documento
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 14
MVC (Model View Controller)
Adicionalmente, cada visão possui associada a si um objeto controlador que auxilia na implementação da interface gráfica associada à visão.Quando um controlador obtém um comando do usuário, ele utiliza informação na visão para modificar o modelo.Definição original: quando o modelo é modificado, ele notifica (padrão GoF Observer) todas as suas visões, que por sua vez, atualizam a si próprias.
Não é o caso no uso dessa padrão em aplicações Web.
8
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 15
MVC em aplicações Web (Java)
Fonte: Argonavis
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 16
Arquitetura MVPO componente model:
Objeto que contém a lógica do negócioNão conhece nada acerca da apresentaçãoPode ser um objeto do negócio, de serviço ou um DataSet.
Aspectos positivos: facilita o reuso da lógica do negócio em diferentes contextos (ambientes).
Web, Smart Client, Mobile, ServicesIdealmente, deve expor interfaces de forma abstrata, em vez de concreta.
Simplifica o teste com objetos MockIsola a implementação do modelo
9
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 17
Arquitetura do MVP
O componente view do MVP é uma estrutura composta de controles de interface com o usuário.Esse componente não contém qualquer comportamento que descreve como os controles reagem à eventos de sistema (ações do usuário).A reação às ações do usuário é posicionada em um objeto separado, o componente presenter.Os manipuladores para as ações do usuário ainda existem nos controles, mas esses manipuladores meramente passam (delegam) o processamento para o presenter.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 18
Arquitetura do MVP
Fonte: http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx
10
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 19
Arquitetura do MVP
O presenter então decide como reagir ao evento.Normalmente, essa reação corresponde ao envio de mensagens aos objetos do modelo (componente model do MVP).
Composto de classes do domínio e de classes de serviço.
Conforme o presenter atualiza o modelo, o componente view é atualizado.Quando o presenter realiza toda a manipulação dos controles, temos o padrão denominado Passive View.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 20
Arquitetura do MVPHá duas razões principais para usar o MVP:
Separar o comportamento da aplicação da interface gráfica.Melhorar a testabilidade
A segunda razão é a mais convincente.A vantagem da separação é que toda a complexidade comportamental é removida da interface gráfica, tornando esta última mais fácil de entender. Essa vantagem é “descompensada” pelo fato de que o controlador deve ainda ser fortemente acoplado à tela.
Nesse caso, há um “ponto de interrogação” bem grande acerca de se vale realmente à pena criar um objeto separado.
Se testabilidade é um fator a ser considerado, devemos decidir o quanto de comportamento permanece na view.
11
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 21
Passive View e SupervisingControllerRecentemente, o MVP foi dividido em dois padrões:
Passive View e Supervising ControllerO padrão Passive View é muito similar ao Supervising Controller.A diferença que o primeiro põe todo o comportamento de atualização da view no controlador, incluindo casos simples.Isto resulta em programação extra, mas significa que todo o comportamento da apresentação é testável.A escolha entre os dois depende:
de que tipo de Data Binding a ser usado e se a equipe concorda ou não em deixar algumas partes da telasem serem consideradas pelos testes no controlador.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 22
Passive View x SupervisingControllerO padrão MVP corresponde na verdade a dois outros padrões:
Passive ViewSupervising Controller
A diferença entre os dois está em quanto o componente View tem conhecimento acerca do componente Model.Quando o View não conhece nada acerca do Model e o Presenter realiza toda a lógica da apresentação, temos o padrão Passive View.Quando uma parte pequena dessa manipulação é feita pelo View, temos o padrão Supervising Controller.Lógica da apresentação (presentation logic)
12
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 23
MVP (Model View Presenter)
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 24
Componente ModelO componente Model corresponde aos objetos que contêm a lógica do negócio.Esse componente não conhece nada acerca da apresentação.Aspecto positivo: facilita o reuso da lógica do negócio em diferentes contextos (ambientes).
Web Apps, Smart Clients, Mobile, WEB ServicesIdealmente esse componente, deve expor interfaces de forma abstrata, em vez de concreta.
Simplificação dos testes com objetos MockIsolamento da implementação do modelo
13
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 25
Componente View
O componente View é uma estrutura composta de controles de interface com o usuário.Esse componente não contém qualquer comportamento que descreve como os controles reagem à eventos de sistema (i.e., a ações do usuário).A reação às ações do usuário é posicionada em um objeto separado, o componente Presenter.Os manipuladores para as ações do usuário existem nos controles da IU, mas eles meramente passam (delegam) o processamento para o Presenter.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 26
Componente Presenter
O Presenter então decide como reagir ao evento notificado pelo componente View.Normalmente, essa reação corresponde ao envio de mensagens a objetos do componente Model.
Composto de classes do domínio e de classes de serviço.Conforme o presenter atualiza o modelo, o componente view é atualizado.
14
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 27
MVP – resumo dos componentesView: exibe os dados e notifica eventos de sistema para o Presenter. Presenter: coordena a comunicação entre o View e a camada de serviços (ou camada de negócio) e éresponsável pela lógica de IU.Model: os dados que devem ser exibidos ou editados no View.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 28
Arquitetura do MVPO Presenter então decide como reagir ao evento notificado pelo componente View.Normalmente, essa reação corresponde ao envio de mensagens aos objetos componente Model.
Composto de classes do domínio e de classes de serviço.Conforme o presenter atualiza o modelo, o componente view é atualizado.Há duas razões principais para usar o MVP:
Separar a complexidade de uma Autonomous View.Melhorar a testabilidade
A segunda razão é a mais convincente.
15
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 29
MVP versus MVC
O MVP é uma variante do padrão MVC, e a idéia básica dos componentes permanece a mesma.A diferença principal é que, no MVP, a tríade estáinvertida:
No MVC, o Controller é responsável pela captura das ações do usuário (e.g., mouseDown, keyDown, etc).No MVP, é o View que captura as ações do usuário; o Presenter então trata esses eventos.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 30
Prós & contras do MVPHá duas razões principais para usar o MVP:
Evitar a baixa coesão de uma Autonomous View.Melhorar a testabilidade (essa é a mais convincente).
Se testabilidade automática deve ser usada, isso conta positivamente para retirar o máximo de comportamento permanece do view. A vantagem da separação é que toda a complexidade comportamental é removida da interface gráfica, tornando esta última mais fácil de entender.
16
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 31
Prós & contras do MVP (cont)
Aspectos positivosJá que a lógica não está atrelada à IU, o MVP facilita a utilização de testes unitários.Posiciona código (responsabilidades) em seu lugar apropriado.Aumenta o reuso da lógica de domínio.Facilita a modificação da IU por designers gráficos.Facilita o uso de TDD (Test Driven Design).Separa adequadamente os aspectos da lógica da aplicação.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 32
Prós & contras do MVP (cont)
Aspectos negativosRequer uma mudança na forma de pensar do desenvolvedorCurva de aprendizado: código é mais abstrato do que no estilo “Autonomouws View” de programação visual.
17
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 33
Supervising Presenter
O estado da apresentação está no ViewA lógica da apresentação está no PresenterO Presenter observa o ViewO Presenter atualiza o ViewO View Presenter conhece o View (acoplamento abstrato)O View não conhece o Presenter
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 34
Passive View x SupervisingPresenterA diferença entre essas duas varianets do MVP estáem quanto o View tem conhecimento acerca do Model.Quando o View não conhece nada acerca do Model e o Presenter realiza toda a lógica da apresentação, temos o padrão Passive View.Quando uma parte pequena dessa manipulação é feita pelo View, temos o padrão Supervising Presenter.
18
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 35
MVPExamples
FPSW-Java
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 36
Exemplo de View
Esse é o componente View (CadastroDepartamentoView) para a funcionalidade de cadastro de departamentos.
19
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 37
CadastroDepartamentoView
public class CadastroDepartamentoViewextends JFrameimplements ICadastroDepartamentoView
O View aqui é uma subclasse de JFrame (formulário em Swing).O View deve implementar uma interface com a qual o Presenter irá interagir (o Presenter não interage com o View diretamente, apenas por intermédio dessa interface).
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 38
ICadastroDepartamentoViewpublic interface ICadastroDepartamentoView {
void desabilitarEntrada();
void habilitarEdicao();
void informarErro(String mensagem);
void modoAlteracao();void modoInclusao();void modoInicial();void modoVisualizacao();
continua...
20
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 39
ICadastroDepartamentoView(cont.)
void limparCampos();void setNome(String nome);void setSigla(String sigla);void setLocalizacao(String localizacao);void setVerbaAnual(Float verbaAnual);
String getNome();String getSigla();String getLocalizacao();Float getVerbaAnual();
}
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 40
ICadastroDepartamentoView(cont.)Note que ICadastroDepartamentoView não possui detalhe algum acerca da apresentação específica (e.g. Swing ou JSP).Isso aumenta a portabilidade do Presenter.O View não conhece o Presenter diretamente, mas notifica este último sobre a ocorrência de eventos de sistema;
21
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 41
Instanciação do Presenter
Na sua instanciação, o objeto Presenter recebe o Viewe os DAO´s de que precisa como parâmetros.O Presenter é um ouvinte (listener) do View.
...CadastroDepartamentoView form = new CadastroDepartamentoView();CadastroDepartamentoController presenter = new
CadastroDepartamentoController(form, DepartamentoDAO.getInstance());
form.inscrever(presenter);...
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 42
Modos do View
O View pode passar por diversos modos (ou estados).Em cada estado, a aparência e o comportamento do View são diferentes.Esses estados se refletem em operações:
void modoAlteracao();void modoInclusao();void modoInicial(); void modoVisualizacao();
É responsabilidade do Presenter controlar o modo no qual o View deve se encontrar, em função das ações do usuário.
22
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 43
Eventos de Sistema
Eventos de sistema ocorrem no View, mas são imediatamente repassados por ele ao Presenter.
public void inscrever(ActionListener listener) {btnIncluir.addActionListener(listener);btnConfirmar.addActionListener(listener);btnCancelar.addActionListener(listener);btnAlterar.addActionListener(listener);btnExcluir.addActionListener(listener);btnPesquisar.addActionListener(listener);
}
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 44
Eventos de SistemaÉ responsabilidade do Presenter decidir o que fazer como reação ao evento.
Ou seja, o Presenter implementa a lógica da apresentação.Para ser um ouvinte do View, o Presenter implementa ActionListener.
public void actionPerformed(ActionEvent e) {String comando = e.getActionCommand();if (comando.equals("Confirmar")) {
confirmarOperacao();} else if (...
}
23
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 45
Uso de um Adapter
Quando a lógica de IU é complexa, uma alternativa écriar adaptatoresAdaptadores são objetos intermediários entre o view e o presenter.Servem para ajudar o presenter na execução da lógica da apresentação.Vejamos o próximo slide...
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 46
DomDomíínionioApresentaApresentaççãoão
ModelModelViewView PresenterPresenter
NotificaNotificaççõesões
Uso de um Adapter (cont)
24
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 47
Modo Inicial
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 48
Modo Inclusão
25
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 49
Modo Visualização
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 50
Modo Alteração
26
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 51
Outro exemplo de MVP (Fowler)
Suponha que haja a necessidade de apresentar dados sobre um objeto de negócio.Variance é um campo calculadoCálculos fazem parte da lógica do negócioDica: não faça cálculos no código da IU
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 52
Interação entre Presenter e View
O presenter solicita à view a exibição de algo semassumir nada acerca de como essa exibição é feita
“O que” apresentar, e não “Como”
‘ Em vez dissoIView.TextBoxName.Text = Cust.Name
‘ Temos issoIView.DisplayCustomer(Cust)
27
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 53
Interação entre Presenter e View
A view fornece notificações para o presenter acercade ações relevantes do usuário.
O presenter é o responsável por iniciar a view.
Public Sub New(ByVal view As IView)_view = viewAddHandler _view.FileNameChanged, AddressOf FileNameChangedHandler
End Sub
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 54
Conclusões
Resumo da arquitetura MVP:View: exibe os dados e notifica eventos de sistema para o Presenter. Presenter: coordena a comunicação entre o view e a camada de serviços (ou camada de negócio) e éresponsável pela lógica de IU.Model: os dados que devem ser exibidos ou editados na tela.
28
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 55
Conclusões
Aspectos PositivosFacilita a modificação da IU por designers gráficos.Facilita o uso de TDD (Test Driven Design).Separa adequadamente os aspectos da lógica da aplicação.
Aspectos NegativosRequer uma mudança na forma de pensar do desenvolvedorCódigo é mais abstrato do que no estilo “Forms & Controls”de programação visual.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 56
Referências
GUI Architectureshttp://martinfowler.com/eaaDev/uiArchs.html
Channel9http://channel9.msdn.com/ShowPost.aspx?PostID=313257
Microsoft sobre MVPhttp://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx
MVChttp://en.wikipedia.org/wiki/Model-view-controller
29
April 08 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 57
Slides Complementares
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 58
Code BehindASP.NET traz uma forma de separar o comportamento da apresentação de seu layout: code-behind.No entanto, ainda há alguns aspectos negativos:
O code-behind ainda pode fazer as vezes do manipulador de eventos em um ambiente orientados a eventos.É praticamente proibitivo realizar testes de unidades no código dos code-behind.
“TDD is difficult to use in some situations, such as graphical user interfaces”
Wikipédia para “Test Driven Development”
30
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 59
Forms & Controls
Os desenvolvedores escrevem os formulários específicos da aplicação que usam controles genéricos.O formulário descreve a disposição dos controles nele.O formulário observa os controles e tem os métodos manipuladores para reagir aos eventos interessantes originados nos controles.A edição simples de dados é realizada com a estratégia “Data Binding”.Alterações complexas são feitas pelos métodos manipuladores de eventos do formulário.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 60
Padrões para Apresentação
Forms and ControlsMVC (Model View Presenter)MVP (Model View Presenter)
31
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 61
Arquitetura do MVP
Fonte: http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 62
Arquitetura MVPO componente model:
Objeto que contém a lógica do negócioNão conhece nada acerca da apresentaçãoPode ser um objeto do negócio, de serviço ou um DataSet.
Aspectos positivos: facilita o reuso da lógica do negócio em diferentes contextos (ambientes).
Web, Smart Client, Mobile, ServicesIdealmente, deve expor interfaces de forma abstrata, em vez de concreta.
Simplifica o teste com objetos MockIsola a implementação do modelo
32
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 63
Arquitetura do MVP
O componente view do MVP é uma estrutura composta de controles de interface com o usuário.Esse componente não contém qualquer comportamento que descreve como os controles reagem à eventos de sistema (ações do usuário).A reação às ações do usuário é posicionada em um objeto separado, o componente presenter.Os manipuladores para as ações do usuário ainda existem nos controles, mas esses manipuladores meramente passam (delegam) o processamento para o presenter.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 64
Arquitetura do MVP
O presenter então decide como reagir ao evento.Normalmente, essa reação corresponde ao envio de mensagens aos objetos do modelo (componente model do MVP).
Composto de classes do domínio e de classes de serviço.
Conforme o presenter atualiza o modelo, o componente view é atualizado.Quando o presenter realiza toda a manipulação dos controles, temos o padrão denominado Passive View.
33
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 65
Arquitetura do MVPHá duas razões principais para usar o MVP:
Separar o comportamento da aplicação da interface gráfica.Melhorar a testabilidade
A segunda razão é a mais convincente.A vantagem da separação é que toda a complexidade comportamental é removida da interface gráfica, tornando esta última mais fácil de entender. Essa vantagem é “descompensada” pelo fato de que o controlador deve ainda ser fortemente acoplado à tela.
Nesse caso, há um “ponto de interrogação” bem grande acerca de se vale realmente à pena criar um objeto separado.
Se testabilidade é um fator a ser considerado, devemos decidir o quanto de comportamento permanece na view.
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 66
Passive View e SupervisingControllerRecentemente, o MVP foi dividido em dois padrões:
Passive View e Supervising ControllerO padrão Passive View é muito similar ao Supervising Controller.A diferença que o primeiro põe todo o comportamento de atualização da view no controlador, incluindo casos simples.Isto resulta em programação extra, mas significa que todo o comportamento da apresentação é testável.A escolha entre os dois depende:
de que tipo de Data Binding a ser usado e se a equipe concorda ou não em deixar algumas partes da telasem serem consideradas pelos testes no controlador.
34
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 67
Modelo MVP
FPSW-Java
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 68
Conclusões
Resumo da arquitetura MVP:View: exibe os dados e notifica eventos de sistema para o Presenter. Presenter: coordena a comunicação entre o view e a camada de serviços (ou camada de negócio) e éresponsável pela lógica de IU.Model: os dados que devem ser exibidos ou editados na tela.
35
April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 69
Conclusões
Aspectos PositivosFacilita a modificação da IU por designers gráficos.Facilita o uso de TDD (Test Driven Design).Separa adequadamente os aspectos da lógica da aplicação.
Aspectos NegativosRequer uma mudança na forma de pensar do desenvolvedorCódigo é mais abstrato do que no estilo “Forms & Controls”de programação visual.
Recommended