Frameworks em ColdFusion
O Christiano Oliveira, iniciou um debate muito interessante na CF-Brasil, onde ele e outros colegas levantaram e discutiram sobre as principais funcionalidades dos frameworks desenvolvidos em ColdFusion.
Quem me conhece sabe que sempre fui bastante interessado e envolvido na produção de backend, principalmente no que tange a qualidade e legibilidade do código no processo de desenvolvimento ou manutenção. Nessa parte do sistema, as regras precisam fazer sentido. É onde a realidade interpretada passa a ser sistêmica e onde os desafios realmente acontecem. Compreender toda sorte de 'eventos' que ocorrem no backend é um grande passo para compreensão da essência do desenvolvimento de software.
Quando falamos de framework, necessitamos de forma direta ou indireta referenciar a separação de conceitos. Separação de conceitos remete à especialização. Especialização remete à divisão de trabalho. E a divisão de trabalho remete a projeto e planejamento com direcionamento preponderante para a produtividade e desenvolvimento em série.
Eu não estaria sendo leviano em dizer que desenvolver sob um framework coeso, faz com que o desenvolvedor aprenda a desenvolver softwares melhores. Afirmo isso principalmente porque essa estrutura tende a direcionar o raciocínio do programador e estabelece limites e fronteiras de codificação, extensão e integração do software, onde a disciplina do programador é um fator principal para se obter sucesso nesse modelo.
Sempre tive o costume de experimentar projetos variados em ColdFusion. Minha finalidade nessa avaliação era mapear a facilidade de leitura do código, padronização, vícios de cada programador e a forma como eles exploravam os recursos disponíveis na CFML. O que eu sempre pude perceber, embora tenha encontrado soluções inteligentes, é que elas sempre eram incompletas em um determinado ponto e tornavam o esforço de adaptação ou o contorno para solucionar algum problema em algo despendioso ou desestimulante, pois de fato fazia uso de técnicas que não eram aderentes com a proposta original da estrutura em questão.
Foi então que comecei a formalizar a idéia de criar um framework para atender ao conjunto de recursos que eu utilizava frequentemente no desenvolvimento dos projetos de meus clientes e a primeira coisa que busquei fazer foi enumerar o que tinha encontrado de legal em cada alternativa que experimentei e compilei em uma lista. É óbvio que existiam bons recursos que não eram compatíveis entre si, sendo assim, optei por escolher os recursos que estivessem mais próximos com o meu estilo, pois esse seria meu estímulo para dar continuidade ao projeto.
Então surgiu o CFShark (inicialmente chamado de WhiteShark) que tem como principal objetivo maximizar a exploração dos recursos existentes da CFML, que seja aderente ao que de melhor o ColdFusion oferece, que esteja bem próximo ao paradigma de orientação a objetos e que possa, apesar dessa diversidade, ser mais simples que as opções populares que temos disponíveis. Em resumo a idéia gira em torno da filosofia do ColdFusion: Desenvolver rápido e com qualidade em menos tempo.
Muitos frameworks foram concebidos numa adaptação de uma abstração de outra linguagem e apenas foram codificados dessa mesma forma no ColdFusion. Isso fez com que limitações e inflexibilidades existentes nessas outras linguagens fossem migradas para o ColdFusion e mesmo que essa migração continue fazendo muito sentido para quem desenvolveu ou tem conhecimento profundo na linguagem que deu origem ao framework em questão, não fará com que a curva de aprendizado de outros desenvolvedores corresponda a expectativa da comunidade. Eu, particularmente, pude constatar uma experiência parecida, foi quando convidenciei a alguns CFErs estrangeiros o meu anseio em desenvolver um framework. Quase sempre era recebido com frases do tipo: "Eu não acredito que vc esteja pensando em fazer isso, os que já existem não te atendem?...". E eu ficava pensando: Esse cara fala como se tivéssemos uma excelente estrutura disponível, escolhida de forma unânime pela comunidade. E depois pensava: Ainda bem que meus amigos e incentivadores brasileiros entenderam meus anseios e sempre me apoiaram.
O mascote não foi escolhido à toa, pois trata-se de um animal que mesmo sendo pré-histórico, conseguiu desde seu surgimento perdurar no topo da cadeia alimentar no seu habitat e isso historicamente é de uma imponência invejável.
No CFShark, os desenvolvedores poderão projetar seus aplicativos com a opção de escolher se irão implementar interfaces com frontend html ou flex. Ou seja, você poderá utilizar o mesmo backend sem a necessidade de adaptar ou com pouca adaptação de seus códigos de uma opção para outra. Isso eu já considero como um diferencial importante em relação às opções que temos disponíveis.
Existe um arquivo de configuração único, onde você tem a opção de parametrizar o framework, inclusive possibilitando para determinados recursos o carregamento de variáveis e componentes em tempo de execução.
Existe a separação de conceitos em MVC, onde essa separação é real, não há mistura entre as partes do sistema e além disso eu criei para ampliar a produtividade dos meus projetos uma camada auxiliar que simplifica a criação dos componentes de apresentação, aumentando a reutilização de código.
Existe uma estrutura funcional para lidar com a tag cfajaxproxy, que simplifica de forma fantástica as interações assíncronas com o servidor, sem fazer uso dos grandes contornos presentes em outras estruturas disponíveis e que torna a compreensão dificilima para alguma adaptação.
Existe a capacidade de extensão de componentes ilimitada. Se você tem ou usa um componente de tratamento de imagem, compactação,etc. Você pode adicionar esses componentes em uma pasta específica e ele poderá ser incorporado no seu aplicativo por meio de uma fábrica de componentes, que provê uma interface única de instanciamento de cada tipo de componente.
A camada de modelo é separada em :
DAO - Data Access Object
DTO - Data Transfer Object (chamado anteriormente de Value Object)
Service - Service Layer
O DAO (veja exemplo) age como uma interface de acesso ao banco de dados. Nele o desenvolvedor pode implementar o modo que for conveniente de acessar ao banco. Como eu uso packages no oracle, inclusive para as consultas, essa parte aqui para mim fica bastante interessante. Como tive que priorizar as necessidades de meus projetos, eu mantive essa parte mais simples, com o CRUD direto, seja com sql normal ou com cfstoredproc. A solução ideal é implementar um camada de abstração para que a interface de acesso seja única para qualquer banco de dados. Existe uma superclasse implementada que provê acesso por meio de uma fachada das variáveis que estão persistentes na memória do servidor, dessa forma, é possível obter os dados de configuração das dsn's e outras configurações.
Adicionalmente, para atender as exigências dos meus projetos, eu criei alguns pacotes em PL/SQL que geram 100% do código interno do banco aa partir das tabelas que são eles : Sequences, Views e Packages CRUD. No ColdFusion eu criei um gerador de objetos de negócios, que também consegue gerar completmente todos os componentes da camada model, bastando apenas codificar os componentes da Service Layer.
O DTO (veja exemplo) é o objeto responsável pelo transporte de dados. Esses dados podem ser simples (number,string,date) ou complexos (outros DTO's). Considero o uso do DTO como fundamental, pois dessa forma alem de prover o evelopamento de dados de forma simples, permite o emprego da tipagem forte, o que faz com que o transporte de dados seja realizado de forma consistente e a fidelidade dos tipos de dados mantenha a aplicação coesa.
A Service layer (veja exemplo)é a camada de serviço da aplicação. No CFShark, funciona como acesso ao Controller (que por sua vez tratará o Model). Somente os métodos dos componentes presentes na Service Layer são expostos ao controller, pois dessa forma, os componentes abstraem a lógica do model de uma forma mais simplificada, possilitando a objetividade da comunicação entre as camadas da aplicação.
A camada de controle (veja exemplo) é composta pelo Controlador e pelo gerenciador de Eventos de Requisição. Os estimulos são capturados durante a execução do Application.cfc, onde por meio de uma variável de controle chamada "Event", são informados o nome do Componente Controlador e o Nome do Método a ser executado, como também é feito no ColdBox.
ex: event=AgendaCultural.dspListagemEventosAgenda
O Gerenciador de Eventos de Requisição, escuta esse estimulo e executa o método invocado em tempo de execução, internalizando todas as variáveis essenciais para o fluxo da aplicação, que são carregadas do Arquivo XML. no momento da inicialização do aplicativo.
No controlador, pode-se facilmente parametrizar todos os dados que estarão presentes na interface. Pode-se instanciar o componente da Service Layer, setar a view, o template, o título da página e os outros dados necessários para alimentar a interface de apresentação. Essas operações, ocorrem no Evento OnRequestStart do Application.cfc, ou seja antes da execução do template.
Na camada de apresentação (veja exemplo), eu desenvolvi uma técnica que otimiza a criação de interfaces. A técnica consiste em separar a tela em partes e pequenos componentes e montá-las pore meio da cfimport(poderia ser cfmodule também). Essa técnica faz com que a necessidade de separação da interface em partes seja o diferencial da produtividade, pois isso além de aumentar a produtividade, irá garantir a simplicidade da manutenção, já que ele irá alterar em um único local que se propagará para todas os outros locais que referenciam esse arquivo.
Na camadade apresentação reside o principal elemento que incrementa a dificuldade de aderência dos frameorks, que éa inflexibilidade da implementação da interface de apresentação, obrigando uma adaptação surreal impraticavel de ser mantida. No CFShark, o desenvolvedor e designer podem trabalhar juntos, pois o trabalho do designer não impacta no trabalho do desenvolvedor. Além disso a estrutura de pastas é bastante enxuta, como vocês podem ver nessa imagem.
O CFShark está em fase de experiência, estamos empregando ele em alguns projetos pequenos e estão surgindo necessidades de implementação e oportunidades de melhoria. Particularmente, acredito que ele alcançou a estabilidade necessária para se tornar compartilhável, no entanto, em respeito aos colegas, só decidirei publicá-lo num SVN público, quando eu puder assumir o compromisso de dar suporte a comunidade, para que juntos a gente possa caminhar e formatar uma estrutura que sirva como referência para o desenvolvimento ágil usando ColdFusion construiída na comunidade brasileira. Contarei com o apio de cada um de vocês.
Finalizando: Há quem diga que desenvolver é uma arte e isso tem um fundo de verdade. O que faz a diferença entre os artistas é a acuidade profissional com ele lida com as melhores técnicas, ferramentas e conceitos objetivando um resultado. E usar um framework não restringe a criatividade, apenas organiza e propoe uma disciplina de como projetar uma solução, seja no presente ou no futuro.
Espero que o CFShark possa ajudá-los no futuro. E aos interessados, o debate está só começando!
Comentários
Marcos Parente escreveu em 04/02/09 10:53
Como sempre o Jeff surpreendendo a todos com o CFShark ...Eu já conhecia o projeto, já havia conversado com o Jeff sobre este, ainda assim, confesso que me surpreendi(positivamente, alias, muito positivamente) com o post do Jeff, acho que isto pelo mesmo motivo postado na lista, o seu perfeccionismo.
Eu tive a oportunidade de ver algumas fotos como no post e estudar “sob” o CFShark. O que no meu ver, foi algo inteligente, pois o Jeff tem modos visados em agilidade, praticidade, e conceitos bem aplicados.
Parabéns Jeff !
Tofinha escreveu em 04/02/09 19:35
Parabéns Jeff,Já conhecia idéia pelas conversas e acredito que vc dará uma grande contribuição com este framework.
Sucesso brother!
Jeff escreveu em 04/02/09 20:48
@Christiano Oliveira,Vamos sim, tenho planejado uma etapa de documentação e screencasts de parametrização do framework e construção de pequenos aplicativos. Estamos muito motivados para compartilhar isso com vocês, mas como ainda temos outros compromissos profissionais tomando bastante tempo, não nos sentimos seguros ainda de disponibilizar e não ter como dar suporte. Obrigado pela resposta!
@Marcos,
Valeu Marcos! É isso ai! tenho absoluta certeza que vc estará sendo um dos primeiros a testar o cfshark
@Tofinha,
Obrigado pelo comentário Tofinha, a gente que tem história antiga nessa comunidade sabe que temos a responsabilidade de redirecionar algumas coisas no aspecto de orientação e compartilhamento de conhecimento, não tenho dúvida que ao tornar público essa e muitas outras iniciativas estaremos aptos a debater sobre novos caminhos para a comunidade de cf brasileira, principalmente para resolvervos questões crônicas como hosting e custo da licença.. obrigado pela mensagem!
Marco Antonio escreveu em 07/04/09 18:56
Jeffão, beleza? Cara, parabéns pelo CFShark! Muito bom mesmo Só quero deixar aqui minha modesta opinião, longe de querer criticar por criticar. Em especial meu comentário vai para o DAO. Não sou muito fã de se criar DAO's para cada entidade e para cada operação(CRUD). Sou fã do estilo de DAO utilizado por alguns frameworks, muito parecidos entre eles, como este:<cfset qGrava = application.DataMgr.saveRecord( 'SCA_LOTE', form )>. O DataMgr(que não é um framework, sabemos) faz do saveRecord o que bem entende: se as chaves passadas condizem com as chaves do banco ele atualiza(update), caso contrário ele mesmo faz um insert. Um get seria algo assim: <cfset qGetDados = application.DataMgr.getRecords(tablename='SCA_Cliente',data=form)>. Simples não? Claro que estou exibindo uma pequena parte do que o DataMgr pode fazer. Mas minha intenção você já sabe, né? Te cutucar para implantar algo simples assim no CFShark ;-) Parabéns pela iniciativa! []s
wilson escreveu em 04/09/09 02:40
Olá a todos. Qual o futuro dessa ferramenta FLEX? O FLEX (que achei muito interessante) veio para ficar?Não sei se devo seguir por esta tecnologia...
Alguma dica?
Tavia escreveu em 18/02/10 02:22
Could you help me. Hello. My Name is Tavia. Help me! It has to find sites on the: Lawsuit prednisolone. I found only this - <a href="http://www.occasioni-vacanze.com/Members/Prednisolone/prednisolone-oral">prednisolone oral</a>. Liver steroids are the inexpensive good good attacks absolutely sought in the disorders nothing, the kidneys, the hypothesis, and the injections and illnesses costing from especially unfortunately drinking of the evidence leading exhibiting of the oral something or the arthritis, prednisolone. Asthma and type were exactly known as overall excess but reducing to sufficient count they are other last for intake's disease, prednisolone. Waiting for a reply :rolleyes:, Tavia from Vatican.
Spa Parts escreveu em 08/03/10 15:47
I added your post to my college Report
RSS Feeds
Christiano Oliveira escreveu em 04/02/09 08:38
Olá Jefferson,Gostei bastante da metodologia aplicada no desenvolvimento, eu uso algo bem semelhante - logico que sem aplicação de um framework - e minha camada de view fica bastante diferente da sua.
Ainda assim, a idéia de usar um Framework é mesmo para que de alguma forma os outros programadores sejam direcionados a executar funções de uma mesma forma.
Vamos esperar o CFShark e espero que ele venha mesmo a contribuir a um codigo cada dia melhor.