No já clássico engarrafamento Barra da Tijuca x Resto do Mundo, vim lendo a Mundo Java. Tem uma matéria bem interessante do Eduardo Guerra sobre a construção de um framework de Negócios/Persistência.
A matéria é muito legal mesmo se você quer entender como um framework é criado, mas tem um problema. Ela é “vendida” como algo do tipo “Não use Hibernate/Outro ORM, use 100% Java!”. Nada explícito no artigo em si, mas nas chamadas e no marketing em torno deste.
Alguns pontos questionáveis:
- Bom, pra começar o Hibernate é 100% Java, então essa afirmação não tem o menor sentido. Depois, Hibernate e Spring, para citar dois, trazem vantagens que frameworks caseiros dificilmente vão ter.
- Eles são bem completos. Quem gastar o tempo e esforço necessários para implementar um framework com as funcionalidades de Spring e Hibernate ou tem muito tempo livre ou não tem acesso á Internet. Ainda que você não precise dos recursos todos não faz sentido gastar tempo reimplementando os que já usa.
- O que ele define é um framework. Utilizá-lo e não a um framework de indústria é conhecido como síndrome do NIH.
-
Depois temos o problema da padronização e documentação. Quem conhece o framework caseiro? Onde eu acho suporte e documentação? Já fui diversas vezes –e sou- vítima de frameworks caseiros e a resposta quase sempre é Manda um e-mail para
”. - Os frameworks modernos também costumam trabalhar com POJOs, o framework caseiro da revista não. Nada impede que o seu framework caseiro o faça, mas voltamos ao primeiro ponto.
- O framework em questão atua basicamente com CRUD de objetos, não preza muito o uso de Domain Models
- O artigo insiste em aumentar a confusão sobre o que raios é um JavaBean, lançando impressões sem o definir.
Novamente: a proposta é louvável, só foi colocada de uma maneira muito ruim. Existem pessoas que realmente não podem utilizar frameworks em desenvolvimento por restrições políticas, um framework como o da matéria pode ajudar em alguns casos. Já vi gente que, no desespero, integra os fontes do spring/struts/etc no seu código para poder os utilizar – vi mais de uma vez, aliás.
Vale a pena ler e acompanhar tendo em mente que trata-se de um framework simples sendo construído didaticamente, e que a modelagem resultante é um CRUD sem Domain Model.
Achei interessnate a proposta do artigo, no caso ele não está sobre nenhum framework. Juntando as idéias q tenho lido aqui sobre DM (sobre spring) com algumas do artigo ele acaba ficando bem mais rico.
Uso Menta não spring, estou abstraindo algumas idéias e estou gostando.
Como você disse, talvez a forma que foi colocado não foi perfeita. Mas acho legal ter publicações desmitificando as framework. Muitas pessoas (a maioria?) olha as framework somente como caixas pretas. Ok, elas existem para serem caixas pretas mesmo, mas se você souber como ela funcionam por debaixo , vai conseguir fazer muito mais coisas com elas.
Olá Pessoal!
Fiquei contente com os comentários sobre o meu artigo! A intenção era mostrar a montagem de uma arquitetura com a filosofia de crie o genérico flexível para configurar as exceções. Logicamente no framework original (inspiração para o artigo) eu utilizo o hibernate e outros frameworks, somente no artigo não daria espaço para colocar isto tudo…
Pelos seus comentários eu acho que uma falha no artigo foi não ter falado dos objetos de domínio em si. O que acontece na prática é que quando já se possui uma infraestrutura de serviços genérica implementada (no caso foi mostrado somente o CRUD), se tem muito mais preocupação com a modelagem das classes de negócio do sistema em si (o que não foi citado no artigo).
Agradeço os comentários e feedback de todos! São comentários como este que nos estimulam a perder algumas noites para escrever um artigo! Abraços!
Citei este seu post no meu blog, mas não consegui fazer um trackback pro seu post. Aqui vai o link:
Coding Dojo