Bem, a pequena Borland usa Struts, a Sun tb usa Struts e mais que isso, baseiam suas soluções nele (e outros projetos Open Source, incluindo frameworks) …
Usando o Hibernate temos AT&T, PriceWaterhouseCoopers, Cisco e mais um punhado …
Mais uma vez, Design Patterns não tem nada a ver com frameworks, em geral um framework emprega um punhado de design patterns para solucionar nossos problemas.
O que o povo tá tentando te explicar é que, em geral, é uma péssima idéia desenvolver uma solução própria sendo que existe um framework que já é testado e aprovado para solucionar o seu problema, mesmo que seja extendendo-o.
Na boa, escuta os conselhos do pessoal que tu vai te dar muito bem.
Eu ja passei por isso, ja comentei em outro topico. Meu primeiro trabalho com Java era dar manutencao em um portal que foi feito por uma SH. O sistema foi feito ± em 1998 usando uma arquitetura interna deles.
Nao queira pegar um carinha desses pela frente.
Acredito que a melhor maneira de tratar isso é criar um, hm digamos padrao de desenvolvimento usando os melhores frameworks para cada caso, mas sempre abstraindo eles (entenda-se escondendo eles) para se algum dia precisar mudar nao se perca muito tempo.
fabgp2001 eu estou gostando dessa ideia de extensão. Legale acredito que muitos que estão lendo essas mensagens estou gostando dessa ideia.
Independencia sem esforço !
Bem melhor que começar do zero !
:lol:
Quase, Fabio… uma coisa que eu tou vendo todo mundo bater boca nessa thread mas que ate agora nao me convenceram direito eh esse papo de “abstrair o framework”…
Custa TAO caro assim trocar um Hibernate ou Struts por outra coisa, que justifica ficar pensando em esconder o framework como se fosse doenca venerea sem realmente saber se vc vai ter que se livrar dele um dia?
Alguem aqui ja teve que fazer uma migracao dessas, e esconder o Hibernate nos DAOs ajudou alguma coisa, ou soh atrapalhou o progresso te impedindo de usar as APIs mais avancadas como a Criteria, pq ela teria que ser usada em lugares “puros”, e te deixando com o minimo divisor comum da historia?
Lógico que custa caro.
Imagine um sistema com 750 telas com ± 900 entidades. Já vi uma de folha de pagamento que tinha isso. Apenas folha, Imagine um ERP.
É lógico de deve-se adotar uma técnologia difinitiva. Ninguém vai pensar estou usando hibernate mais talvez amanhã eu uso XYZ.
Mas melhor previnir do que remediar.
Agora aquela perguntinha que eu fiz de integrar o modelo hibernate com
interface gráfica é possivel ?
O exemplo de tamanho de campo é apenas a ponta do iceberg.
“Logico que custa caro!” nao eh uma prova la muito boa, jprogrammer. Quanto custa o trabalho de isolar o framework comparado com o custo de usar ferramentas de refactoring boas pra mudar a implementacao caso isso um dia seja necessario?
Note que, na primeira situacao, o custo eh maior que o risco, mas nao quer dizer que o risco nao exista: voce soh tah arriscando outra coisa, que eh a de nao usar tudo que o framework tem pra oferecer e acabar empacando, ou tendo que aumentar a complexidade do software por causa disso.
Eu discordo, aliás, é exatamente isso que estou fazendo.
Estou desenvolvendo uma aplicação aqui em que as classes de negócio conversam com um DAO e este com o Hibernate. Fiz dessa forma pra se um dia quiser trocar o Hibernate por Entity ou outra forma de persistência, fique sem maiores dores de cabeça.
Ai voltamos para a excelente pergunta deste topico.
Re: Patterns:Onde?Quando?
Os patterns são usados principalmente para dar elegancia ao software e reusabilidade dentro da própria aplicação sem uso de ferramentas externas e geradores de código.
Se for para usar isso tem:
e-gen (free)
genexus (gera para várias linguagens)
Compuserve Uniface (também gera para várias linguagens).
[quote=louds]Prevenir a substituição de um framework só faz sentido se ele for proprietario e a empresa dona falir.
[/quote]
Hmmm, mesmo que ela não venha a falir… É impressionante o que os vendors são capazes de fazer de uma versão pra outra mesmo que você seja premium customer…
jprogrammer, eu uso padrões o máximo que posso, mas sempre seguindo as seguintes regras:
:arrow: Não introduzir padrões
:arrow: Fazer a coisa mais simples possivel
:arrow: Refatorar
:arrow: Sem dó
:arrow: Achei algo que parece com um padrão conhecido? Formaliso.
Padrões só devem ser usados inicialmente quando já são a alternativa mais simples; por exemplo, usar FrontController caso o projeto tenha adotado Struts, WebWork ou qualquer outro f/w MVC.
[quote=cv]Quase, Fabio… uma coisa que eu tou vendo todo mundo bater boca nessa thread mas que ate agora nao me convenceram direito eh esse papo de “abstrair o framework”…
Custa TAO caro assim trocar um Hibernate ou Struts por outra coisa, que justifica ficar pensando em esconder o framework como se fosse doenca venerea sem realmente saber se vc vai ter que se livrar dele um dia?
Alguem aqui ja teve que fazer uma migracao dessas, e esconder o Hibernate nos DAOs ajudou alguma coisa, ou soh atrapalhou o progresso te impedindo de usar as APIs mais avancadas como a Criteria, pq ela teria que ser usada em lugares “puros”, e te deixando com o minimo divisor comum da historia?[/quote]
Concordo plenamente CV, muita gente faz ou ja fez (eu por exemplo) essa de tentar esconder os frameworks usados para quando forem mudar nao ter problemas. Hoje eu tamebm nao penso muito nisso, prefiro usar o que tenho da melhor maneira possivel e simplificar sempre.
[quote=louds]jprogrammer, eu uso padrões o máximo que posso, mas sempre seguindo as seguintes regras:
:arrow: Não introduzir padrões
:arrow: Fazer a coisa mais simples possivel
:arrow: Refatorar
:arrow: Sem dó
:arrow: Achei algo que parece com um padrão conhecido? Formaliso.
Padrões só devem ser usados inicialmente quando já são a alternativa mais simples; por exemplo, usar FrontController caso o projeto tenha adotado Struts, WebWork ou qualquer outro f/w MVC.[/quote]
concordo com o louds.
fora os padrões mais comuns, ou faceis de identificar, normalmente é nos refactorings que vou identificando a possibilidade de utilização.
tentar pensar nisso antes é muito dificil, e vai acabar trazendo coisas desnessarias ao projeto.
[quote=jprogrammer]Porque não se pode usar o poder dos framworks abstraindo-os ?
Então não posso usar os recursos os SO porque o java abstrai.[/quote]
Pq a partir do ponto em que voce poe uma cerca em volta dum framework, vc ta impedindo partes do seu codigo de chegar nele, mesmo quando faria sentido que elas o acessassem (criteria e paging do Hibernate no controller web, por exemplo)
Alias, a sua segunda afirmacao responde bem a pergunta: existem dezenas, talvez centenas, de recursos que os sistemas operacionais disponibilizam para as aplicacoes mas que nao estao acessiveis atraves das APIs do Java pq nao sao multiplataforma, exigindo todo tipo de malabarismo com JNI ou COM Wrappers.
É impressionante o que os vendors são capazes de fazer de uma versão pra outra mesmo que você seja premium customer… 
