1. Utilizando o Padrão PresentationModel em Aplicações Flex Eric Cavalcanti ecavalcanti@gmail.com @ericoc

2. Sobre mim Eric Cavalcanti Mestre em Engenharia de Software pelo CESAR.EDU Certificado ScrumMaster pela ScrumAlliance Engenheiro de Software da ID S/A Background Trabalha com desenvolvimento de Software há mais de 10 anos . Instrutor Adobe Flex da Imedia Brasil. Professor no Curso de Especialização em Gestão Ágil de Projetos do CESAR.EDU e da Pós-Graduaçaõ em Front-EndEngineering & Design da Faculdade Marista Idealizador e principal desenvolvedor do projeto FireScrum (Flex e Java) Idealizador do FireKanban (Flex e Java)

3. O Problema

4. O Problema Geralmente uma View em um aplicação contém controles que exibem dados do domínio de sua aplicação. O usuário pode alterar os dados e submeter tais alterações.

5. O Problema A View geralmente: recupera os dados do domínio manipula eventos dos usuários altera outros controles da View em resposta a tais eventos submete as alterações efetuadas nos dados do domínio.

6. O Problema Incluir todo esse código na View pode torná-la uma classe complexa, difícil de manter e testar. Ocasionalmente, seria difícil compartilhar o código com uma outra View que necessita do mesmo comportamento.

7. Motivação Você quer aumentar a cobertura dos seus testes unitários automáticos (Views são difíceis de testar automaticamente). Você quer compartilhar o código entre Views que necessitam do mesmo comportamento Você quer separar a lógica de negócio da lógica de interface do usuário (UI) para que o código fique mais fácil de entender e manter.

8. Motivação Você quer permitir que o profissional de designer possa facilmente criar e modificar o visual da interface do usuário da sua aplicação. Os dados que você quer exibir necessitam de alguma conversão, validação ou formatação antes de serem exibidos na interface do usuário.

9. Solução

10. PresentationModel

11. O que é o PresentationModel?

12. PresentationModel em uma frase! “É uma forma de mover o estado e a lógica da view para uma outra classe.”

13. Uma imagem vale mais do que mil palavras! View PM Model ContatoDetalheView.mxml ContatoDetalhePM.as ContatoModel.as

14. Principais características O estado fica no PresentationModel A lógica fica no PresentationModel A Viewobserva o PresentationModel e atualiza de acordo com o mesmo O PresentationModelobserva o Model A View"conhece" o PresentationModel O PresentationModel"não conhece" a View Padrão recomendado pela Adobe com o novo Cairngorm 3. Padrão recomendado pela Microsoft para aplicações WPF e Silverlight com o nome de Model-View-ViewModel (MVVM)

15. Mais sobre o PresentationModel Um PresentationModel é uma "abstração" de uma View O PresentationModel representa o comportamento e o estado de uma View A View representa a projeção ou a renderização do PresentationModel na tela

16. ContatoDetalheView.mxml <fx:Script> <![CDATA[ import br.com.flexmania.event.ContatoEvent; import br.com.flexmania.event.ExibirTelaPrincipalEvent; import br.com.flexmania.model.presentation.ContatoDetalhePM; [Bindable] publicvarpm:ContatoDetalhePM; ]]> </fx:Script>

17. ContatoDetalhePM.as [Bindable] publicclassContatoDetalhePMextendsAbstractPM { publicvarisAtualizando:Boolean; publicvarcontatoAtual:ContatoVO; publicfunctionmanterContato(contato:ContatoVO):void { ... } ... AgendaFlexMania.mxml (Application) <presentation:ContatoDetalhePM id="contatoDetalhePM" contatoAtual="{_model.contatoModel.contatoAtual}" isAtualizando="{_model.contatoModel.isAtualizando}"/>

18. E como é feito esse negócio da Viewobservar e representar o PresentationModel?

19. Simples!

20. Utilizando Data Binding!

21. Data Binding para o PresentationModel <fx:Script> ... [Bindable] publicvarpm:ContatosListaPM ... </fx:Script> <mx:DataGridwidth="100%" id="dgContato" dataProvider="{pm.contatos}" doubleClickEnabled="true" change="pm.selecionarContato(dgContato.selectedItemasContatoVO);“ doubleClick="pm.exibirAtualizarContato(dgContato.selectedItemasContatoVO)"> <mx:columns> <mx:DataGridColumnheaderText="Nome" dataField="nome" width="40"/> ... </mx:columns> </mx:DataGrid>

22. Bidirecional (two-way) data binding do Flex 4 <fx:Declarations> <vo:ContatoVO id="contato" email="{pm.contatoAtual.email}" nome="{pm.contatoAtual.nome}" telefone="{pm.contatoAtual.telefone}" codigo="{pm.contatoAtual.codigo}"/> </fx:Declarations> <mx:Form width="100%" height="118" > <mx:FormItemlabel="Nome"> <mx:TextInput width="236" id="txtNome" text="@{contato.nome}"/> </mx:FormItem> <mx:FormItemlabel="Telefone"> <mx:TextInput width="236" id="txtTelefone" text="@{contato.telefone}"/> </mx:FormItem> <mx:FormItemlabel="E-mail"> <mx:TextInput width="236" id="txtEmail" text="@{contato.email}"/> </mx:FormItem> </mx:Form> <s:Button label="Submeter" width="93" click="pm.manterContato(contato)" />

23. Testabilidade Uma vez que as classes PresentationModel são totalmente desacopladas da View, a lógica que elas contém são mais facilmente testadas.

24. Melhoria na separação de responsabilidades Se cada PresentationModel representa uma abstração de uma View, então, podemos considerar que a união dos PresentationModel podem ser consideradas como o Modelo de toda sua User Interface. Comportamentos comuns de apresentação podem ser refatorados em classes base e compartilhada por todos os PresentationModel.

25. Classe base do PresentationModel publicclassAbstractPMextendsEventDispatcher { privatevarfirstShow:Boolean = true; protectedvardispatcher:IEventDispatcher = AppEventDispatcher.instance; publicfunctionhandleShow():void { if(firstShow) { handleFirstShow(); firstShow = false; } else { handleSubsequentShows(); } } publicfunctionhandleFirstShow():void { // to beoverriden } publicfunctionhandleSubsequentShows():void { // to beoverriden } }

26. E o quanto de estado e lógica devem ser extraídas da View?

27. Tanto quanto possível!

28. Exemplos Dados da View (ex. uma lista de produtos filtrada) O Estado da View (ex. o selectedIndex da ViewStack) Lógica da View (ex. determinar o estado de um botão em um form)

29. Mas certos tipos de lógica talvez seja melhor serem deixadas na View

30. Comportamento fortemente acoplados a parte gráfica ou ao framework como por exemplo animações e operações de Drag-and-Drop, são candidatas a ficarem na View

31. Abordagens do PresentationModel Hierárquica Componentizada

32. Hierárquica

33. Componentizada

34. Resposta à mudanças Hierárquica View 3 precisa ser movida para View 2

35. Resposta à mudanças Componentizada View 3 precisa ser movida para View 2

36. Arquitetura da Aplicação ViewLayer PresentationLayer DomainLayer IntegrationLayer Model View Business Delegate CMD PM Controller CMD Back-End CMD

37. Código por favor!!

38. Conclusão O PresentationModel é um padrão útil para aplicações Flex testáveis Ao mover o estado e a lógica usados na apresentação de dados e na manipulação de eventos do usuário para o PresentationModel, ele pode ser mais facilmente testado e entendido do que colocado diretamente na View no bloco Script. Como a interface com usuário é algo muito volátil é preferível utilizar a abordagem componentizada em vez da hierárquica

39. Referências Presentation Model, Martin Fowler, http://martinfowler.com/eaaDev/PresentationModel.html Presentation Patterns - Presentation Model, Paul Williams, http://blogs.adobe.com/paulw/archives/2007/10/presentation_pa_3.html Applying the Presentation Model in Flex, Tom Sugden, http://blogs.adobe.com/tomsugden/2009/08/applying_the_presentation_mode.html PresentationModel, Microsoft, http://msdn.microsoft.com/en-us/library/ff647585.aspx Flex Client Architecture & Best Practices, Børre Wessel - Adobe Consulting, http://blogs.adobe.com/borre/Flex_Client_Architecture_and_Best_Practices.pdf Flex Development with Cairngorm, Alistair McLeod, http://blogs.adobe.com/amcleod/2008/12/max_milan_-_fle.html Refatorando o ModelLocator do Cairngorm, Pablo Souza, http://blog.dclick.com.br/2008/11/16/refatorando-o-modellocator-do-cairngorm-parte-i/pt/

40. Obrigado! Eric Cavalcanti ecavalcanti@gmail.com @ericoc