Quanto tempo não!??! sabe como é alguns pequenos sistemas pra termina, outros pra começar
bateria de provas na Faculdade, Problemas que me dão dor de cabeça! e porai vai...
Mas então, vamos ao que interessa!
É impressionante como as aplicações em Flex está crescendo, e infelizmente, a galera pega o Flex Builder, vai arrastando os componentes fazendo algumas telas, e já acham que dominam o pai Flex,
e se acham pronto a desenvolverem sistemas! infelizmente é assim que acontece na maioria das vezes.
O próprio conceito, Web2.0, nem ao menos sabem do que se trata o.O
Mas não estou aqui para julgar ou algo do tipo!! não é??
+)
Gerenciamento de Memória do Flash Player
Um dos principais problemas em desenvolver aplicações com Flex, é desenvolver telas, tendo um controle de armazenameto de memória,
"o problema sobre o não real descarregamento da memória está muito mais ligado à natureza do Flash e do Flex SDK"
Por: Fabio Terracini
- A arquitetura do Display List não permite (na verdade dificulta muito) que um DisplayObject seja removido completamente da memória, e o SDK é tão interligado que é muito difícil remover todas as referências de alguma instância para esta estar completamente sujeita ao GC (Garbage Collection.
- Assim, mesmo que vc faça button = null, parte dele continuará na memória. E isso piora ainda mais quando o objeto for para o displaylist. Um objeto "aparecer na tela" também consome memória.
Isto é, infelizmente o Flash Player, não tem um GC (Garbage Collection) muito aprimorado, ele vai carregando e carregando a memória, até travar o browser, ou gerar erros.
Não que eu esteja condenando o tão pequeno e simples Flash Player porém muito poderoso! e sim aqueles que desenvolvem suas aplicacões seja ela em puro Flash, ou Flex , de maneira desogarnizada.
Para isso..
Framework MVC - Cairngorm
No Mundo O.O existem os Framewoks MVC Model View Controller ou Modelo-Visão-Controlador, estes responsáveis por organizar e separar o negócio da camada view, isto é, tem um cara ali por traz em seu desenvolvimento, organizando tudo!
Para trabalhar com o Flex, existe o Cairngorm, Poderoso Framework MVC para aplicações RIA, este provido de uma empresa alheia, hoje fundida a Adobe! +)
O Cairngorm utiliza os seguintes design patterns:
• View Helper
• Front Controller
• Command
• Sequence Command
• Business Delegate
• Service Locator
• Value Object
• View Locator
• Model Locator
• Responder
View Helper
O View Helper é um auxiliar para a view, ou seja, a nossa tela. Seu propósito é literalmente separar a lógica da tela com a tela em si, ou seja, funções que manipulam a tela dos elementos de interface da tela (grids, listas, e afins). Desse modo, mantém a tela responsável por formatar os dados, enquanto a responsabilidade de pegar, processar e preparar os dados é do View Helper.
Front Controller
A medida que os use cases de um determinado software aumentam, aumenta também a quantidade de serviços da aplicação, inclusive de serviços comuns, como autenticação e log. Desse modo, o Front Controller é um ponto de contato para cada request, separando a camade de negócios da camada de apresentação. O Front Controller fica “escutando” os eventos ocorridos e controlando o fluxo da aplicação.
Command
Quanto mais código é adicionado no Controller referente aos use cases, cresce a sua complexidade e dificulta sua manutenção. Desse modo, propõe-se reduzir a complexidade do Controller reduzindo sua lógica. Com o Command, o Front Controller fica livre para a sua principal tarefa, delegar para alguém fazer o trabalho. O Command, por fim, é implementado por use case, gerenciando a resposta de um método remoto. Como é por use case, dois Commands podem chamar o mesmo método remoto, mas em seu tratamento de resultado, podem realizar tarefas diferentes.
Business Delegate
O Business Delegate propõe não expor os detalhes de implementação de serviços de negócio. Dessa forma, ele visa ocultar a complexidade de comunicação remota, acessando a camada de negócio. As conexões cliente-servidor ficam centralizar e o mesmo método pode ser utilizado por diferentes Commands.
Service Locator
Criar conexões de diferentes serviços não é a preocupação do desenvolvedor em Flex, já que os dados que ele irá utilizar independem do tipo de serviço remoto. O Service Locator é uma abstração da implementação de serviços, escondendo de seu cliente (o Business Delegate) os detalhes de conexão.
Value Object
O Value Object (VO) resolve o problema de transferência de dados entre camadas da aplicação, já que o que importa não é como os objetos são representados (em ColdFusion, em Java, etc..), mas sim os dados desses objetos. O VO é um container para dados que representa uma entidade do sistema, possibilitando interoperabilidade entre as camadas.
View Locator
O View Locator é utilizado para localizar e retornar a instância de uma tela, de modo que seja possível, em qualquer lugar da aplicação, manipular uma tela através de seu repesctivo View Helper.
Model Locator
O Model Locator é a memória da aplicação, onde os objetos de dados (um objeto que popule um comboBox, ou um grid, as imagens utilizadas na aplicação, etc) utilizados na aplicação são iniciados e guardados, como um “storage”. O Cairngorm utiliza a API de Data Binding do Flex no Model Locator, de modo que basta a variável ser alterada no Model Locator para que o dado reflita diretamente na tela.
Responder
O Responder é implementado para associar o objeto responsável pelo tratamento do resultado de uma chamada remota. Sua implementação é no Command.
Event Broadcaster
O Event Broacaster é utilizado pela aplicação para notificar o Controller (que está “escutando”) que algo aconteceu.
Diagrama de Exemplo:
Links Sobre o Cairngorm:
http://labs.adobe.com/wiki/index.php/Cairngorm
http://www.iterationtwo.com/open_source_cairngorm.html
Componente ViewStack
Enfim, para quem quer começar uma grande sistema, muito bacana usar o Framework, porém
nem sempre são aplicações grandes! e como fazer para que mais tarde eu não tenha problemas com memória!?!?
Ta aí uma solução que a Adobe implementar entre a versão Flex 1.5 para a Flex 2.0, a modolurização!
isto é, um componente (ModuleLoader) que carrega swf`s externos em tempo de execução, poderoso com certeza, porem os mais críticos dizem que não é a melhor solução!
Logo!! +)
Existe o componente ViewStack!! também poderoso e inteligente componente que faz o consumo de memória ficar baixo!
Quando usar um, preste atenção em seu comportamento!, Ex:
Você tem várias abas dentre um ViewStack, ao abrir pela primeira vez, ele só descarrega na memória logo também na maquina cliente, o que irá exibir somente nesta tela, as outras abas, não são carregados absolutamente nada! o que para uma aplicação Web, se torna muito importante!
Estas outras Abas só irão ser carregadas após selecionadas, depois armazenadas em cache no Navegador do Cliente!
O Jeito de Programar Web 2.0
Bacana não!! Agora uma coisa lhes digo! se você é da época em que se programava com Delphi, Centura, VB, ou umas dessas linguagens Desktop, kra... infelizmente! temos que reaprender a programar, e rever todos os conceitos Web2.0!!
Porque digo isso, antigamente, quando se criava telas de cadastro, Ex:
Você tinha um Main que por sua vez Chamava a tela de Cadastro de Estados, e se não houvesse tal pais para tal estado, deveria Fechar a tela, ou abrir mais uma tela para Cadastrar o Tal país!! o.O
Complicado não? a você que pensa assim, lhes apresento a Web2.0, +)
Onde não existem inúmeras Telas! e sim uma Tela inteligente, capaz de ter todo o conteúdo necessário em apenas algumas telas!
Quer entender melhor do que estou falando!?
Pega esse Link
Show de Bola não!? viu o carrinho de compras?!? o componente de Comparativo!?! o Estilo de Contato!?
Bacana neh.... é isso ae.... A Web 2.0 (Já chamo de 3.0! =) vindo para Inovar e Facilitar a nossa vida!!
Resumindo! +)
- Para Aplicações Maiores, utilizar um Framework MVC, no caso o Cairngorm
- Para Aplicações Menores, interessante usar o componente ViewStack
- Antes de começar a fazer a Telas, pense Web2.0! pense Flex! +)
ah Muito Obrigado a todos aqueles que tem acompanhado as noticias aqui do Blog!
O Números de visitas tem aumentado bastante! =)
Abraço Pessoal!!
\o/
Referências
Architecting Flex Applications: Cairngorm and RIA Microarchitecture
CFGigolo
DClick
2 comentários:
Só uma observação: faz tempo que o nome do padrão não é VO e a definição não é exatamente a do post.
http://martinfowler.com/eaaCatalog/dataTransferObject.html
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
Certamente hoje eu absorvo e prego as idéias do Cairngorm de modo diferente de antigamente (e de quando fiz o diagrama).
O View Locator é um pattern que quebra a separação de responsabilidades do MVC, possibilitando que o Controller (não confundir com o pattern Front Controller) manipule a View diretamente. E comumente tenho visto o View Helper sendo utilizado de forma errada, encapsulando a lógica de negócio e não apenas formatando dados da tela. São elementos do Cairgorm que eu não uso mais, por exemplo.
O Model Locator continua peça na chave em conjunto com o data binding, e contém não apenas dados mas também funcionalidades. Isto é, não representa apenas o estado, mas também como o sistema funciona. Ah, e vale notar que ele é um "Locator": ou seja, é responsabilidade do desenvolvedor criar o Model de seu sistema, de acordo com o domínio deu seu aplicativo.
O Cairngorm não é apenas para aplicativos grandes. Pequenos aplicativos também pode se beneficiar da micro arquitetura que ele fornece. Algumas outras coisas também mudaram da versão 0.99 para cá, como o Event Broadcaster que agora chama-se Cairngorm Event Dispatcher.
Sobre o VO, ele também é chamado de Transfer Object ou Data Transfer Object (alguns dizem que há pequenas diferenças, ou não) e a essência deles em sintese é a mesma: transferir dados entre camadas. Acredito que o time do Cairngorm mantenha VO por compatibilidade.
Recomendo o diagrama do http://cairngormdocs.org/. Ele certamente está mais atualizado e coerente com o que acredito do Cairngorm no presente.
Ah, sobre a memória, vale dizer que o que afirmei é sobre a arquitetura do Display List (os dois "bullets" do texto). A função do Garbage Collector é desalocar da memória objetos que não são mais usados, e isso ele faz muito bem. Mas para isso os objetos não podem conter referências, e limpar as referências não é responsabilidade do GC, e sim do desenvolvedor.
[]s
Fabio Terracini
Postar um comentário