Módulo II Modelo MVPwebserver2.tecgraf.puc-rio.br/.../Cidade_DSOO/aulas/Modulo2_MVC/… ·...

View
5
Download
0
Category

Documents

Preview:

Citation preview

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)

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/

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

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

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.

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)

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.

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

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

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.

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)

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

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.

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.

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.

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.

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.

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.

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

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;

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.

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

}

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)

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

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

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)

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.

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

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”

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)

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

April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 63

Arquitetura do MVP

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.

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

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:

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 67

Modelo MVP

FPSW-Java

April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 68

Conclusões

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