Módulo II Modelo MVP Prof. Ismael H F Santos April 08 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 1 Referências (livros) April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 2 1
Referências (na Web) GUI Architectures http://martinfowler.com/eaadev/uiarchs.html Channel9 http://channel9.msdn.com/showpost.aspx?postid=313257 Microsoft sobre MVP http://msdn.microsoft.com/msdnmag/issues/06/08/designp atterns/default.aspx MVC http://en.wikipedia.org/wiki/model-view-controller April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 3 Referências (na Web) Passive View http://www.martinfowler.com/eaadev/passivescreen.html Supervising Controller (Supervising Presenter?) http://www.martinfowler.com/eaadev/supervisingpresenter. html GUI Architectures http://martinfowler.com/eaadev/uiarchs.html Podcasts http://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 4 2
FPSW-Java Modelos Camada de Apresentação April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 5 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 6 3
Introdução Responsabilidades 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ção Disposiçã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 7 Padrões de software Autonomous View Model View Controller Model View Presenter Supervising Presenter (ou Supervising Controller) Passive View Presentation Model View Helper April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 8 4
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 9 Autonomous View Características O estado da apresentação está no View A 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 10 5
Autonomous View Vantagem: Simplicidade na implementação. Desvantagens Difícil de aplicar testes unitários (unit testing), Separação de responsabilidades (separation of concerns) 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 11 MVC (Model View Controller) Padrão utilizado para separar a lógica da apresentação da 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!). April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 12 6
MVC (Model View Controller) Um arquitetura de desenho comumente utilizada para aplicações com interface gráfica. Inicialmente desenvolvido para a linguagem Smalltalk Quando 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 13 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 14 7
MVC em aplicações Web (Java) April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 15 Fonte: Argonavis Arquitetura MVP O componente model: Objeto que contém a lógica do negócio Não conhece nada acerca da apresentação Pode 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, Services Idealmente, deve expor interfaces de forma abstrata, em vez de concreta. Simplifica o teste com objetos Mock Isola a implementação do modelo April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 16 8
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 17 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 18 9
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 19 Arquitetura do MVP Há 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 20 10
Passive View e Supervising Controller Recentemente, o MVP foi dividido em dois padrões: Passive View e Supervising Controller O 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 tela sem serem consideradas pelos testes no controlador. April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 21 Passive View x Supervising Controller O padrão MVP corresponde na verdade a dois outros padrões: Passive View Supervising 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 22 11
MVP (Model View Presenter) April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 23 Componente Model O 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 Services Idealmente esse componente, deve expor interfaces de forma abstrata, em vez de concreta. Simplificação dos testes com objetos Mock Isolamento da implementação do modelo April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 24 12
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 25 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 26 13
MVP resumo dos componentes 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 no View. April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 27 Arquitetura do MVP O 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 28 14
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 29 Prós & contras do MVP Há 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 30 15
Prós & contras do MVP (cont) Aspectos positivos Já 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 31 Prós & contras do MVP (cont) Aspectos negativos Requer uma mudança na forma de pensar do desenvolvedor Curva 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 32 16
Supervising Presenter O estado da apresentação está no View A lógica da apresentação está no Presenter O Presenter observa o View O Presenter atualiza o View O 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 33 Passive View x Supervising Presenter A 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 34 17
FPSW-Java MVP Examples April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 35 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 36 18
CadastroDepartamentoView public class CadastroDepartamentoView extends JFrame implements 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 37 ICadastroDepartamentoView public 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 38 19
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 39 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 40 20
Instanciação do Presenter Na sua instanciação, o objeto Presenter recebe o View e 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 41 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 42 21
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 43 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 44 22
Uso de um Adapter Quando a lógica de IU é complexa, uma alternativa é criar adaptatores Adaptadores 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 45 Uso de um Adapter (cont) Notificações View Presenter Model Apresentação Domínio April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 46 23
Modo Inicial April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 47 Modo Inclusão April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 48 24
Modo Visualização April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 49 Modo Alteração April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 50 25
Outro exemplo de MVP (Fowler) Suponha que haja a necessidade de apresentar dados sobre um objeto de negócio. Variance é um campo calculado Cálculos fazem parte da lógica do negócio Dica: não faça cálculos no código da IU April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 51 Interação entre Presenter e View O presenter solicita à view a exibição de algo sem assumir nada acerca de como essa exibição é feita O que apresentar, e não Como Em vez disso IView.TextBoxName.Text = Cust.Name Temos isso IView.DisplayCustomer(Cust) April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 52 26
Interação entre Presenter e View A view fornece notificações para o presenter acerca de ações relevantes do usuário. O presenter é o responsável por iniciar a view. Public Sub New(ByVal view As IView) _view = view AddHandler _view.filenamechanged, AddressOf FileNameChangedHandler End Sub April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 53 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 54 27
Conclusões Aspectos Positivos 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. Aspectos Negativos Requer uma mudança na forma de pensar do desenvolvedor Có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 55 Referências GUI Architectures http://martinfowler.com/eaadev/uiarchs.html Channel9 http://channel9.msdn.com/showpost.aspx?postid=313 257 Microsoft sobre MVP http://msdn.microsoft.com/msdnmag/issues/06/08/desi gnpatterns/default.aspx MVC http://en.wikipedia.org/wiki/model-view-controller April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 56 28
Slides Complementares April 08 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 57 Code Behind ASP.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 58 29
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 59 Padrões para Apresentação Forms and Controls MVC (Model View Presenter) MVP (Model View Presenter) April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 60 30
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 61 Arquitetura MVP O componente model: Objeto que contém a lógica do negócio Não conhece nada acerca da apresentação Pode 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, Services Idealmente, deve expor interfaces de forma abstrata, em vez de concreta. Simplifica o teste com objetos Mock Isola a implementação do modelo April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 62 31
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 63 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 64 32
Arquitetura do MVP Há 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 65 Passive View e Supervising Controller Recentemente, o MVP foi dividido em dois padrões: Passive View e Supervising Controller O 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 tela sem serem consideradas pelos testes no controlador. April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 66 33
FPSW-Java Modelo MVP April 05 Prof. Ismael H. F. Santos - ismael@tecgraf.puc-rio.br 67 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 68 34
Conclusões Aspectos Positivos 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. Aspectos Negativos Requer uma mudança na forma de pensar do desenvolvedor Có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 69 35