Frameworkenstein
February 3rd, 2010 | 
Author: Muitas vezes fiquei pensando no quão legal seria eu construir um framework. Afinal, a cada mês um novo framework aparece no Google, por que não mais um? Imaginem um framework chamado “Fabiowork” ou “FazTudoWork”. Aposto que pelo menos meia dúzia de acessos o site teria só pela curiosidade da galera em descobrir quem é o responsável por tanta “criatividade”.
Calma, não vão sair digitando esses nomes no Google. Perda de tempo, podem apostar. Bom, o termo “fabiowork” encontra 542 resultados fabiowork (0,36 segundos). Impressionante.
Não estou aqui para falar mau de frameworks, até porque uso e recomendo, como o bom e velho Struts, Spring, bla bla bla work, etc.
Eles são úteis, muito, economizam tempo com implementações e definições repetitivas para a maioria das aplicações comerciais que são construídas.
Agora, construir um? Não, obrigado.
Por que?
Bom, prefiro continuar a usar frameworks já conceituados no mercado que possuem equipe altamente especializada e dedicada a manter tudo na mais perfeita ordem a harmonia. Prefiro continuar a ler documentos e usar aplicações de referência onde é realmente REFERÊNCIA. Prefiro, mais ainda, focar no entendimento do negócio.
Não estou muito afim de usar frameworks construídos por profissionais que dizem para não fazer A mas mantém a aplicação de referência e sua respectiva documentação fazendo A.
Não estou afim de ouvir dos profissionais que construíram o framework que eu ter 1 classe abstrata (com apenas algumas implementações) no momento 1 da aplicação é “aumentar a complexidade da aplicação prematuramente”, que eu posso “fazer um refactory mais pra frente”.
Você quer construir um framework? ÓTIMO. Mas por favor, não construa Frameworkenstein nem se torne um Arquitetoenstein. Combinado?
Posted in 
Tags: 
E nem use Struts, pelo amor de Deus!! Já estamos em 2010!
Existe a era antes Ruby on Rails e a era pós Rails. De uma certa forma todos os frameworks foram influenciados ou deveriam ser influenciados. Um dos baseados no Rails são VRaptor 3 (Java), DJango (Python) e CakePHP.
Eu diria o seguinte: se você tem uma linha de produtos de software em que foi percebido um problema recorrente, pense em construir um framework(claro, depois de procurar soluções no mercado), senão pule fora. Normalmente essas soluções resolvem problemas bastante específicos (ex:”capturar os cliques do mouse no logotipo da empresa”), não são tão abrangentes quanto o struts. Crescem com o tempo e a necessidade.
O que acontece com frequência é a irresponsabilidade de pretensos arquitetos que criam esses frameworkensteins para justificar seus “títulos”.