Mas o problema é quando você faz isso e essa solução já foi criada e já é extensivamente usada por outros programadores!!!
Suponha que vc criou uma super-jprogrammer-lib.jar, e você sai da empresa para trabalhar em uma empresa melhor, daí o seu substituto nem imagina como usar sua lib e ainda por cima mete a faca em você dizendo que você poderia usar tal solução open source que já é basntante conhecida no mercado!!!
Você consegue garantir que todos consigam realmente usar e sem dificuldades a sua super-jprogrammerlib.jar???
1 - Isso com certeza nunca seria uma decisão minha sozinho.
2 - Para que existe documentação ?
Acho que é inteligente você ter bibliotecas próprias para reuso.
Já conheci empresas em que chegavam mais longe desenvolvendo seu proprio IDE e até pasmen “LINGUAGEM PRÒPRIAS”.
Existem sistemas no mercado que funcionam a partir de regras de negócio implementadas a partir do usuário.
Não é errado adaptar ferramentas para necessidades especificas.
É lógico depende muito o tipo de necessidade que você tenha.
Agora me fale se e possivel eu aplicar um hibernate da vida ou strus facilmente em um tipo de aplicação como essa ?
Se você é uma software house que possue sistemas padronizados e não projetos sob encomenda não seria mas produtivo implementar soluções mais especificas ?
Depende. Se for um meta banco, por que não? Agora, se o usuário cria campos “físicos” na tabela, você também não tem problemas com as classes que representam isso? E implementar as interfaces do Hibernate para suportar isso, como EntityPersister, não seria mais fácil? O Hibernate normalmente é flexível o suficiente para esses casos “estranhos”.
Reconheço que as vezes a falta de conhecimento em uma ferramenta faz a gente criticar antes de conhecer…
Mas sempre procuro manter um sistema indepentente de uma ferramenta na medida do possível. Daí a necessidade dos patterns.
Pattern DAO. Muito bem sacado.
Agora chamar o session.save direto é suícidio.
Sim realmente não depende.
O problema principal não é a implementação, mas sim a interface exposta pelo programador.
Se não for flexivel pode custar caro.
ex:
Concordamos que o hibernate é hoje a melhor solução de persistencia.
você tem.
session.save explado no sistema inteiro.
um belo dia muda para hibernate 10, 11, XYZ…
se você tiver
DAO.save, precisa apenas mudar em um único ponto.
Isso deve ser valorizado. Os programadores criarem arquiteturas inteligentes. Tecnologias por traz são muito importantes, mas são substituiveis…
Hibernate suporta o mecanismo predileto de 9 entre 10 desenvolvedores “enterprise”… HashMap
Ou seja, se você acha que esse negocio de POJO é muito inflexivel e exige muito código, o Hibernate te permite mapear as entidades em gloriosos HashMaps. Gloria gloria aos maravilhosos softwares e frameworks que usam o incrivel paradigma “HashMap oriented software development”.
E quanto a usar soluções caseiras no lugar de frameworks que sabem oque fazem. Bom, eu sou 100% simpático ao argumento do mister_m. Estenda eles, não substitua. Com um pouco de esforço, geração de código e umas classes de apoio, você consegue enlatar boa parte do processo de escrever software crud.
Fora isso, escrever software de infraestrutura, como hibernate, é algo completamente diferente que software para um usuario final.
Vejo varios lugarem que fazem diariamente essa escolha “esperta” e quase sempre o motivo é garantir o emprego de cada um.
Acho que você não entendeu que é possível fazer algo como:
interface Dao {
public void save( Object o );
}
class JdbcFromHellDao implements Dao {
public void save( Object o ) {
// descobre qual objeto que é, procura por algum tipo de
// mapeamento para saber quais são os atributos e quais são as colunas
// da tabela, usa SPCSPL para montar a query,
// faz a conexão, cria o prepared statement, popula o ps,
// executa a query
}
}
class HibernateDao implements Dao {
public void save( Object o ) {
session.save( o );
}
}
Apesar de ter feito questão de dar uma pinicadinha em jdbc puro (hehe), o que quis mostrar mais uma vez é que Hibernate e DAOs não tem necessariamente nada a ver um com o outro. Quem quiser usa junto oras
E mais um detalhezinho: o Hibernate será muito em breve um padrão da Sun. EJB3 vai usá-lo para fazer a persistência dos EJBs.
É isso mesmo que eu gostaria de dizer.
Já que o hibernate hoje é a melhor solução, mesmo que não agrade gregos e troianos, que se faça de uma maneira inteligente (junto com o DAO).
Porque o Thiago falou que DAO.create é suicidio.
É melhor que session.save direto.
Lipe,
Hoje então você chama o session.save() direto nos seus objetos do domínio?
E se acontecer de mudar a forma de persistência, se por exemplo quiser mudar de Hibernate pra Entity?
[quote=jprogrammer]Não acredito nessa de criar implementações proprias gera bugs e retrabalho.
Depende do nível de complexidade.
Os padrões da SUN já nos dão bastante suporte para criarmos soluções com qualidade.[/quote]
Implementacoes proprias adicionam complexidade extra ao software. Quanto mais complexidade, mais bugs, e quanto mais bugs, mais retrabalho. Voce pode nao acreditar num fato, mas ele vai continuar existindo
Os “padroes da Sun” (que nao sao da Sun ;)) dao suporte para se construir software no modelinho da J2EE, e muita gente ja deu de cara na parede por achar que isso era tudo que precisava. Imagino que isso nao tenha acontecido com vc ainda, entao talvez vc ainda esteja em tempo de ler de novo essa thread e repensar umas coisas. Nao que eu esteja metendo o bedelho no seu trabalho ou no jeito que voce escreve o seu software, mas eu me importo com isso a partir do momento que eu me imagino dando manutencao ou fazendo algum refactoring numa app dessas.
[quote=Rafael Nunes]Lipe,
Hoje então você chama o session.save() direto nos seus objetos do domínio?
E se acontecer de mudar a forma de persistência, se por exemplo quiser mudar de Hibernate pra Entity?[/quote]
Oxe, você entendeu meu exemplo ao contrário hehe estou incentivando o uso de padrões.
Cv pode criticar a vontade. Quero aprender e estou aberto a críticas.
Sim estou considerando tudo que o pessoal está escrevendo.
Não quero reiventar a roda, mas também não quero ser o programador limitado e preguiçoso.
Tudo deve ser baseado no bom censo.
Sei das minhas limitações (são muitas), sei o que é viável para realidade, mas ter criatividade e personalidade é bem interessante.
Já houvi muita gente falar.
Bom use o struts pois todo mundo usa.
É o mesmo que você falar. Use o windows, todo mundo usa.
É lógico que você tem garantias como suporte, documentação experiências, know-how. Mas se não se encaixa perfeitamente.
Mas ter um monte de coisas para usar uma.
Não é mais fácil eu usar uma servlet e dar uma request dispatcher para um JSP.
O que isso tem de errado.
A simplicidade. Não vejo nenhum retrabalho nisso.
Qualquer implementação posterior tenho RequestWrappers, Filters, etc. Um monte de padrões…
Ah, entendi o contrário, é daquele jeito que você faz então? Porque é assim que eu tô fazendo, vi seu post e já tava pensado: ‘Que merda que eu fiz dessa vez?!?’…
[quote=jprogrammer]Bom use o struts pois todo mundo usa.
É o mesmo que você falar. Use o windows, todo mundo usa.[/quote]
Isso significa que existe o jprogrammer OS™ ? :mrgreen:
(afinal de contas nao precisamos de tanta coisas que os SOs fazem, suporte a drivers e essas coisas, podemos escrever só pro nosso hardware e tá tudo certo, funciona que é uma beleza.)
Samuel que nao tem nada pra fazer e queria postar neste tópico *
O cara se tá de sacanagem.
Eu quero fazer uma analogia.
Quem você acha que é melhor ?
Windows X Linux.
A maioria usa Windows, mas realmente é o melhor ?
E não quero escovar bits em minhas implementações.
Não quero substituir o hibernate ou struts. Mas prefiro usar que tem de padrão nativo.
Junto com patterns de desenvolvimento eu consigo coisa melhor que com alguns frameworks para DETERMINADAS NECESSIDADES.
Agora pergunta as grandes e médias companias de software (PEOPLESOFT, SAP, MICROSIGA, DATA SUL) se eles usam struts ou hibernate. Eu sei que alguns usam JAVA e J2EE. Pois são sistemas padronizados e não sob encomenda. Acredito que para as Consultorias de encaixam ferramentas mais genéricas.
