Módulo II Modelo MVPwebserver2.tecgraf.puc-rio.br/.../Cidade_DSOO/aulas/Modulo2_MVC/… · FPSW-Java April 05 Prof. Ismael H. F. Santos - [email protected] 6 Introdução

1

April 08 Prof. Ismael H. F. Santos - [email protected] 1

Módulo II Modelo MVP

Prof. Ismael H F Santos


Referências (livros)

2


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


Referências (na Web)

Passive Viewhttp://www.martinfowler.com/eaaDev/PassiveScreen.html

Supervising Controller (Supervising Presenter?)http://www.martinfowler.com/eaaDev/SupervisingPresenter.html


Podcastshttp://polymorphicpodcast.com/shows/mv-patterns/

Stub Generator (mais curiosidade do que realidade...)http://www.polymorphicpodcast.com/tools/mvp-stub/

3


Modelos Camada de

Apresentação

FPSW-Java


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


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.


Padrões de softwareAutonomous ViewModel View ControllerModel View Presenter

Supervising Presenter (ou Supervising Controller)Passive ViewPresentation Model

View Helper

5


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.


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


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.


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



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



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


MVC em aplicações Web (Java)

Fonte: Argonavis


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


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.


Arquitetura do MVP

Fonte: http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx

10


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.


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


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.


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


MVP (Model View Presenter)


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


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.


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


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.


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


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.


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


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.


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


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


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


MVPExamples

FPSW-Java


Exemplo de View

Esse é o componente View (CadastroDepartamentoView) para a funcionalidade de cadastro de departamentos.

19


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).


ICadastroDepartamentoViewpublic interface ICadastroDepartamentoView {

void desabilitarEntrada();

void habilitarEdicao();

void informarErro(String mensagem);

void modoAlteracao();void modoInclusao();void modoInicial();void modoVisualizacao();

continua...

20


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();

}


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


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);...


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


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);

}


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


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...


DomDomíínionioApresentaApresentaççãoão

ModelModelViewView PresenterPresenter

NotificaNotificaççõesões

Uso de um Adapter (cont)

24


Modo Inicial


Modo Inclusão

25


Modo Visualização


Modo Alteração

26


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


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


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


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


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.


Referências


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


Slides Complementares


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


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.


Padrões para Apresentação

Forms and ControlsMVC (Model View Presenter)MVP (Model View Presenter)

31


Arquitetura do MVP

Fonte: http://msdn.microsoft.com/msdnmag/issues/06/08/DesignPatterns/default.aspx


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


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.


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


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.


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


Modelo MVP

FPSW-Java


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


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.

Documents

Módulo II Modelo MVPwebserver2.tecgraf.puc-rio.br/.../Cidade_DSOO/aulas/Modulo2_MVC/… · FPSW-Java April 05 Prof. Ismael H. F. Santos - [email protected] 6 Introdução