Vantagem em desenvolver um framework WEB próprio

Assuntos Gerais
#21

Sim, eu estava falando de frameworks no geral. Aliás, o título original do seu tópico não falava em web.

Mas as primeiras respostas servem para web também, afinal, a sua apilcação pode não ser uma aplicação web “ortodoxa” (pode ser, por exemplo, um MMORPG, um sistema que tenha que mostrar dados em tempo real, etc).

Se vc está falando mais especificamente de sistemas de cadastro e relatório, aí sim, não tem muito porque reinventar a roda.
No máximo, vale a pena adapta-la.

Um framework próprio (web ou não) também pode ser desenvolvido pelos seguintes motivos:

  1. Simplificação da arquitetura: Como todos os componentes são da mesma empresa, não é preciso fazer proxies, classes de conversão ou trabalhar com várias classes que fazem exatamente a mesma coisa. Fora que um framework específico não tem diversas classes de uso geral, ou diversas opções de flexibilização (muitas vezes obrigatórias), que são inúteis no domínio específico do problema.
  2. Performance;
  3. Compatibilidade: Os componentes de diversas partes do sistema integram-se perfeitamente e de maneira suave. Não há risco de uma versão futura de um dos softwares gerar incompatibilidade com outras partes do sistema.
  4. Know how: O interesse em fazer um software próprio pode estar em fortalecer o conhecimento do time e provar para o mercado a capacidade técnica. Há ganhos imediatos, já que após projetar um framework, os profissionais passam a ter um conhecimento muito profundo sobre os seus “rivais”.
#22

[quote=ViniGodoy]Sim, eu estava falando de frameworks no geral. Aliás, o título original do seu tópico não falava em web.

Mas as primeiras respostas servem para web também, afinal, a sua apilcação pode não ser uma aplicação web “ortodoxa” (pode ser, por exemplo, um MMORPG, um sistema que tenha que mostrar dados em tempo real, etc).

Se vc está falando mais especificamente de sistemas de cadastro e relatório, aí sim, não tem muito porque reinventar a roda.
No máximo, vale a pena adapta-la.

Um framework próprio (web ou não) também pode ser desenvolvido pelos seguintes motivos:

  1. Simplificação da arquitetura: Como todos os componentes são da mesma empresa, não é preciso fazer proxies, classes de conversão ou trabalhar com várias classes que fazem exatamente a mesma coisa. Fora que um framework específico não tem diversas classes de uso geral, ou diversas opções de flexibilização (muitas vezes obrigatórias), que são inúteis no domínio específico do problema.
  2. Performance;
  3. Compatibilidade: Os componentes de diversas partes do sistema integram-se perfeitamente e de maneira suave. Não há risco de uma versão futura de um dos softwares gerar incompatibilidade com outras partes do sistema.
  4. Know how: O interesse em fazer um software próprio pode estar em fortalecer o conhecimento do time e provar para o mercado a capacidade técnica. Há ganhos imediatos, já que após projetar um framework, os profissionais passam a ter um conhecimento muito profundo sobre os seus “rivais”.[/quote]

desculpe minha ignorância a respeito, mas para mim um framework web próprio sempre foi uma biblioteca de tags própria e algumas classes de persistência. Então seria mt mais do que isto?

#23

Bom, se você levar em consideração que existem livros inteiros sobre classes de persistencia e sobre padrões de integração (o MVC é um deles), sim, vai ver que há muito mais coisa do que isso.

Vamos pegar um exemplo clássico.

Numa possível arquitetura web,

  1. Você pode usar AJAX para apresentação dos dados (digamos o GWT);
  2. Classes do Jakarta commons para controlar o controle de conexões, gerar logs, etc;
  3. Hibernate para a persistência em si.
  4. Struts para fazer o meio de campo (controller).

Só aí, já são 4 arquiteturas. Existe uma forte possibilidade de haver classes duplicadas.
Existe a chance do hibernate logar usando log4j e o struts fazer isso usando o pacote java.util.logging.
Além disso, os formatos de log não serão padronizados.

Existe também a possibilidade de dois componentes dessa arquitetura serem conflitantes.

E, certamente, há DIVERSOS objetos entre as camadas, que não seriam necessários se tudo não precisasse ser tão flexível (lembre-se você pode substituir qualquer um dos frameworks citados, e há código prevendo isso). Isso pode vir a comprometer a performance num sistema crítico e certamente leva a um código mais complexo (no mínimo, com mapeamentos de classes, classes proxy, conversões de tipo, etc).

#24

Bom, se você levar em consideração que existem livros inteiros sobre classes de persistencia e sobre padrões de integração (o MVC é um deles), sim, vai ver que há muito mais coisa do que isso.

Vamos pegar um exemplo clássico.

Numa possível arquitetura web,

  1. Você pode usar AJAX para apresentação dos dados (digamos o GWT);
  2. Classes do Jakarta commons para controlar o controle de conexões, gerar logs, etc;
  3. Hibernate para a persistência em si.
  4. Struts para fazer o meio de campo (controller).

Só aí, já são 4 arquiteturas. Existe uma forte possibilidade de haver classes duplicadas.
Existe a chance do hibernate logar usando log4j e o struts fazer isso usando o pacote java.util.logging.
Além disso, os formatos de log não serão padronizados.

Existe também a possibilidade de dois componentes dessa arquitetura serem conflitantes.

E, certamente, há DIVERSOS objetos entre as camadas, que não seriam necessários se tudo não precisasse ser tão flexível (lembre-se você pode substituir qualquer um dos frameworks citados, e há código prevendo isso). Isso pode vir a comprometer a performance num sistema crítico e certamente leva a um código mais complexo (no mínimo, com mapeamentos de classes, classes proxy, conversões de tipo, etc). [/quote]

Bom…pelo o que vc falou, um framework próprio seria apenas uma junção de outros frameworks (customizada mas não deixaria de ser uma junção), correto?

#25

Esse é um exemplo…

Pense nos requisitos de um framework de persistência bancário, ou da receita federal, por exemplo.
É bem provável que você não vá achar uma solução de persistência satisfatoriamente escalável, segura (e integravel com mainframe?).

Na verdade, tudo depende dos requisitos do sistema, da capacidade técnica da empresa e dos planos dela de curto, médio e longo prazos.

#26

Aqui desenvolvemos um framework para criação dinâmica de interfaces JSF+AJAX através de anotações feitas nos pojos de persistência. A vantagem é que ficou do jeito que precisávamos, e o tempo gasto em relação ao tempo que vamos economizar daqui pra frente é insignificante. Além do que, como o Vinny já havia dito, não vamos correr o risco do fornecedor do framework abandonar o projeto.

Rodrigo.

#27

E oq vc acha de colaborar com algum framework já existente?

#28

Olá

Este é um dos principais motivos por que sou contra desenvolver um framework web próprio. A chance de uma equipe se desfazer é muito maior do que a de um projeto open source com grande número de usuários mixar.

Se vamos falar de documentação, número de pessoas usando e testando, gente blogando ou escrevendo artigos, discussão no GUJ, etc. e tal dificilmente sobrarão argumentos justificando desenvolver mais um framework web.

[]s
Luca

#29

Que tal uma biblioteca e não um framework, Rodrigo?

#30

[quote=rdantas] Aqui desenvolvemos um framework para criação dinâmica de interfaces JSF+AJAX através de anotações feitas nos pojos de persistência. A vantagem é que ficou do jeito que precisávamos, e o tempo gasto em relação ao tempo que vamos economizar daqui pra frente é insignificante. Além do que, como o Vinny já havia dito, não vamos correr o risco do fornecedor do framework abandonar o projeto.

Rodrigo.[/quote]

:smiley: Legal, fizemos aqui um, entretanto com o frontend do ZK, com uso de richlets, também anotando os pojos. O que começou por curiosidade acabou se tornando coisa séria…

#31

[quote=ViniGodoy]…
3. A empresa não corre o risco do projeto de terceiros ser abandonado (como já aconteceu com o Jython, por exemplo);
…[/quote]

Desculpe, mas de onde você tirou que Jython foi abandonado?

http://www.theserverside.com/news/thread.tss?thread_id=48627

#32

ok…mas qts recursos vcs acham q deva ser destinado para se fazer um framework web com persistência, tag libs, controle de transações, ajax, etc?

#33

Nenhum! Essa porra toda ja existe. Se vc tem um problema pra resolver, resolva o problema e ai sim abstraia as generalizacoes. Ou seja, ao inves de reinventar o Spring, melhore o Spring. :wink:

#34

Nenhum! Essa porra toda ja existe. Se vc tem um problema pra resolver, resolva o problema e ai sim abstraia as generalizacoes. Ou seja, ao inves de reinventar o Spring, melhore o Spring. ;)[/quote]

Como nenhum? ele simplesmente vai nascer do nada?

#35

[quote=eduacsp]ok…mas qts recursos vcs acham q deva ser destinado para se fazer um framework web com persistência, tag libs, controle de transações, ajax, etc?[/quote]Pelo amor de Deus, outro framework não!

oq vc precisa que nem o vRaptor, Spring, Struts, Richfaces, e mais os outros 5 trilhões não resolvem?

#36

Boa! Que seja…

#37

[quote=Luca]Este é um dos principais motivos por que sou contra desenvolver um framework web próprio. A chance de uma equipe se desfazer é muito maior do que a de um projeto open source com grande número de usuários mixar.

Se vamos falar de documentação, número de pessoas usando e testando, gente blogando ou escrevendo artigos, discussão no GUJ, etc. e tal dificilmente sobrarão argumentos justificando desenvolver mais um framework web.[/quote]

Não entendi o seu primeiro argumento. O segundo é muito justificável e concordo plenamente.
Mas… se a equipe se desfizer, aí não terá mesmo porque o framework existir, não?

O fato é que as vezes se faz muito alarde em cima de tecnologias open source que não tem nem uma equipe grande, nem uma comunidade disposta a mante-la. O exemplo que eu citei foi bom, o Jython. Foi simplesmente abandonado, paralizou no tempo. Quem apostou também no Visual Editor para editar telas no Eclipse também se ferrou (o mesmo para os amantes da IDE DevCpp, de C++).

O próprio Groovy tem uma equipe de desenvolvimento relativamente pequena e tem sido muito falado. As chances dele ser abandonado ainda existem e não são pequenas.

O fato é que existem poucos usuários dispostos a manter softwares open source. Essa história de “só baixar os fontes e mudar você mesmo” certamente não é verdade. Para um ou outro bug, ok. Mas se for para fazer assim sempre, então não há ganho. É muito difícil entender software de terceiros e, se for para você mesmo dar manutenção, é melhor fazer o seu próprio framework.

Ok, nada disso é válido para frameworks muito consolidados ou mantidos por grandes empresas como o jakarta tomcat, hibernate, glassfish, netbeans, etc…

É só ver quantas pessoas, naquele outro tópico sobre melhorias do GUJ, disseram que vão baixar o JForum e modifica-lo (quase nenhuma)… e quantas vão realmente fazer isso (provavelmente nenhuma).

Mas minha opinião é. Para o caso da web existem sim bons frameworks em todas as camadas que resolvem os problemas, com comunidades grandes e ativas, e grandes empresas dando suporte. Não faz sentido redesenvolve-los. O máximo é fazer como o rdantas: um framework de integração, para tornar mais suave o trabalho do mapeamento das classes de negócio.

É bom lembrar também que o custo de desenvolvimento de um framework próprio é muito alto. Envolve ter profissionais que tenham conhecimento profundo de projeto. Exceto os casos de onde o framework é o negócio da empresa, certamente, é maior do que uma empresa de pequeno (e as vezes até de médio) porte pode pagar.

#38

Olá

Exatamente! Cada integrante novo que entra na equipe para substituir o que saiu terá que aprender do zero a tal da solução caseira. Não há chances de contratar alguém que já conheça o framework open source. E os que saem muitas vezes o fazem pela insatisfação de usar algo que não serve para nada lá fora (já vi isto mais de uma vez).

E as trocas nas equipes acontecem mesmo em empresas com baixo turn over. Basta uma promoção.

[]s
Luca

#39

Tudo bem, até pode ser, mas como queríamos algo customizado à nossa necessidade optamos por desenvolver. Quanto ao desmantelamento da equipe, estamos tomando os devidos cuidados documentando tudo. Além do mais, usando annotations, ficou fácil demais, qq bom analista destrincha o código tranquilamente.

#40

Neste caso, a relação do custo X benefício para a construção do framework foi muito válida.
E pelo que eu entendi ele aproveitou o JSF.
Então ele não crioou nada do zero.
Apenas automatizou a criação das tela.