Actionscript/ Actionscript Frameworks/ AS 3.0/ Design Patterns/ Dev. Software/ Dicas/ Flex/ frameworks/ OSFLash

Flex, Design Patterns e frameworks

Tá havendo uma discussão magnífica na lista Flex-Brasil sobre Design Patterns, Frameworks, metodologia de desenvolvimento de software e como organizar e distribuir sua aplicação rica.
Por incrível que possa parecer é sempre a mesma pergunta que eu recebo entre e-mails, visitas técnicas e mini treinamentos ” Você pode nos ensinar qual a melhor forma de desenvolver aplicações escalonáveis no Flex? “. E justamente nessa semana aparece um tópico desse na lista e todos trocando informações apontando seus pontos de vistas, se re-descobrindo e não poderia deixar passar de lado isso e abrir mais 3 categorias novas no site e colar aqui minha singela opinião sobre todo esse assunto gerado na comunidade que pelo que parece possa crescer mais ainda depois desse artigo.
Segue abaixo meu ponto de vista dado:

From: Igor Costa
Date: Jul 24, 2007 3:22 PM
Subject: Re: [flex-brasil] Re: Frameworks
To: flex-brasil@yahoogrupos.com.br

Tou gostando desse tópico, se continuarmos assim, prova que todos aqui estão amadurecendo.

Vou dá meu ponto de vista, não necessariamente deve ser regra, mais baseando-se em minha experiência em aplicativos de larga escala e aplicações usando e distribuindo entre equepes.

Flex é uma solução tecnologia que facilita a criação da camada de apresentação, ela foi feita com essa idéia e permanecerá sempre com esse foco, já que o Flex ele torna particalmente rápido o desenvolvimento de forms, window, containers, layout de interface de aplicações que requer muito esforço, digo isso por que eu sei como é fazer isso à alguns anos atrás com Flash ou Swing.
Entao basicamente cada framework existente para criação de telas de aplicações ricas em Flex, sendo elas baseadas em carningorm, parana, model-glue, são justamente focados em disparos de eventos, customização de eventos, controle lateral de software, em fim são facilitadores da vida de quem gosta de não inventar a roda e quer um desenvolvimento mais hábil.

Em outro lado o grande porém de se usar frameworks como esse é a falta de documentação necessária para tal, falta de exemplos e popularização dos mesmos. Existe um paradigma que eu sempre converso com meus desenvolvedores que é, se o AS3 me dá a possibilidade de criar o meu e o Flex aceita esse tipo de criação, eu me pergunto, por que usar frameworks externos se você pode criar seus próprio framework e assim agilizar determinadas áreas de produção do seu software sem ter que ficar se preocupado com como ele será reagido ou como pode ele influenciar drasticamente o ciclo de desenvolvimento com Flex.

Ao meu ver, cada trabalho específico em desenvolvimento seja ele em grande ou pequena escala não é necessário está criando o céu e a terra como fez Deus, mais sim criar métodos próprios, suas próprias classes de evento, seus próprios paradigmas de desenvolvimento escalonável entre outros frameworks para integração de back-ends sem precisar está usando soluções extras. Resumindo a questão, use o favorecimento de soluções rápidas, não esqueça que a tecnologia Flex é para isso, RAD(Rapid Application Development), eu sou adepto ao re-uso de minhas próprias classes abstratas, da reciclagem de meus próprios componentes criados em aplicações que já foram desenvolvidas sem está com o uso desses problemas no ciclo geral.

Flex como camada de back-end:

Nesse ponto o Flex tem avançado e muito em criar as melhores soluções RPC para está fazendo o bind dos dados nos seus componentes já pre-definidos. Não há hipótese alguma do Flex se voltar para essa questão e criar frameworks que façam esses tipos de acessos a base de dados de forma mais fácil, Já existem soluções open-source e pagas que faz isso por você procure no www.riaforge.com onde tem muita coisa rolando por lá como o as3 lightwave remoting.

Flex respeita o processo de desenvolvimento em 3 camadas, dessas quais todas tem seus principais papeis no desenvolvimento geral da aplicação, Interface, camada lógica e Base de dados. Essa estrutura sempre gostei de preservar e manter, já que isso torna a organização final de meu aplicativo mais legível para outros desenvolvedores que possam agregar valor de talento ao time e assim ficar fácil de se entender.

Agora eis a questão, depois de tudo isso onde se encaixa o fator de criação e elaboração de aplicações em equepe junto ao framework do Flex?

Primeiro passo a se desenvolver é criar um padrão à ser usado, nomenclatura de variáveis, declarações de constantes, arquetetura de organização de classes e sobre posicionamento de arquevo extras necessários.

Usar um padrão em sí, existem vários o mais popular é MVC ( Model View Control) que nesse momento é o que é menos propício a falhas.
Nomenclatura de variáveis é algo que tem sua importância mais nao corresponde há 90% do desenvolvimento do software, mais sim uma parte fundamental para começar a criar alguma coisa, considere declaração de variáveis como várias peças de um carro em uma linha de montagem, cada uma tem sua parcela de contribuição para que o carro funcione, então tomando em conta sobre isso, diga-se que correspondem não só 90% mais sim 10% do total, onde o favor mão de obra e idéias de desenvolvimento contam com 50% do total.

A arquetetura de organização é um fator que pesa tanto quanto a criação de mão de obra quanto componentes, constantes, que influem 50% do valor agregado ao desenvolvimento.
Organizar é algo que serve para deixar claro o objetivo de cada classe, heranças que elas tem, particularidades como métodos próprios, propriedades exclusivas e tipos de acessos a objetos do palco.(Stage Class)., Exemplo abaixo:

Main Application
– assets( local onde se guarda, css, imagens, arquevos de texto, html para helps, swf de acesso)
– package
-Aplicando-se nomenclatura à qualquer uso dependendo muito para não usar palavras reservadas do as3.
ex.: br.flexbrasil.utils
br.flexbrasil.com
br.flexbrasil.controls
br.flexbrasil.formatadores

– views – Local onde vão está guardados seus componentes criados em mxml que recebem ou faz parte do seu framework de UI.
– controle – Caso você não use um pacote específico para controle você pode adicionar um externo que ficará mais fácil o acesso a tais procedimentos de coleção, filtragem de dados, passagem de parametros, CRUD, etc.
-Modules – Caso você use uma estrutura modular dividindo uma aplicação em módulos que podem ser feitos separadamente e podem ser criados por distintos membros do time de desenvolvimento sem atrapalhar o arqueteto geral da criação.

Depois disso tudo, só delegar bem as tarefas e o fluxo de criação do aplicativo sai do forno, lembrem-se flex é para camada de apresentação, outro produto como o Livecycle dá uma ajuda ao Flex UI nesse sentido, facilitando somente a comunicação com classes Java e usando alguns recursos do JMS e DMS.
Porém por regra de usos, Flex deixa livre o desenvolvedor à escolher quais elementos ele poderá usar no back-end e assim deixando o livre harbítrio dele escolher se deverá usar XML, HTTPService, Webservice ou coleção de dados por query ou recordset.
Diferenças entre esses usos cada caso é um caso que deve-se analisar pelo número geral de registros. Tudo tem um limite como o datagrid que só suporte 1 milhão de registros.

Basicamente são esses os conceitos que eu tenho adotado com minha experiência e espero ter contribuído com todos vocês.

Abraços
Igor Costa
www.igorcosta.com
Soluções em aplicações RIA

Participe dessa discussão também, eu tenho visto ótimos pontos de vistas que podem ser utilizados e novas metodologias possam ser re-aplicadas.
Code refactoring é a premisa básica do XP em sempre todos os casos muito de code-refectoring tem sido usado bastante. Eu uso.