Franco, as duas críticas que vc fez, atacando diretamente o texto e a autora, não tiveram uma argumentação sequer.
Se vc quiser continuar só na agressão, sugiro que se retire da discussão. Você não é obrigado a ler o tópico. [/quote]
Faz parte!!
Em se falando de hibernate, temos um problema serio, como o Java é Tipificado, e não podemos criar campos em tempo de execução em uma classe (Sim, tem, mas ninguem é loco de ficar usando javassist a torto e adireita, e mesmo assim não é nativo), a solução mais elegante é o ActiveRecord do Rails, na minha opnião, você não se atem a detalhes da base, só se preocupa com detalhes do objeto, tratar os dados, não fica aquele monte de Anotações ou XML.
Acredito que as vezes a complexibilidade está logicamente na propria linguagem, existem alguns pontos que o java não é flexivel como outras linguagens, isso nos força a encontrar um meio de equilibrio entre as partes para utiliza-los.
Eu trabalhei num laboratório de informática da faculdade, mas era diferente, tinham um certo tempo (diga-se bom tempo), para ficarmos estudando, quando as demandas de projetos aumentaram e eu pulei fora, pois meu conhecimento estava fora do salario que me pagavam.
O detalhe, é que também sempre achei o desenvolvimento em Java (Usando Hibernate, Spring), muito chato e tedioso, levava uma tarde para mapear as entidades de um projetinho rediculo, até tentei criar um gerador para suprir minhas necessidades, mas encontrei tantos disponiveis, que acabei não usando nenhum. Até fiquei contente enquanto lia as definições do Spring, finalmente eu posso configurar meu DataSource em Java, sem XML, e é logico com annotations, do jeito que essas annotations vem crescendo vamos acabar fazendo em XML por que vai ficar mais legivel.
Eu não acho o fim do mundo configurar xml não, para quem já trabalhou para uns bancos ai, xml do hibernate é moleza… Não tem outra thread onde o pessoal vai fazer um “desafio” e desenvolver algo em equipe? Não acompanhei tudo, mas tem várias páginas lá, acredito que algo esteja rolando. Pq não aproveitam e tentam desenvolver uma solução que elimine parte destes problemas?
Porque quem desenvolve soluções para Java provavelmente já se deu conta que não vale a pena o esforço, já que se trata de uma fraqueza da linguagem utilizada, o problema não está no XML ou nos frameworks. Existem ótimas bibliotecas Java por ai, mas se vc anda precisando de muito XML ou frameworks web na sua aplicação Java, talvez fosse melhor servido por uma linguagem dinâmica para JVM.
[quote=Felagund]Em se falando de hibernate, temos um problema serio, como o Java é Tipificado, e não podemos criar campos em tempo de execução em uma classe (Sim, tem, mas ninguem é loco de ficar usando javassist a torto e adireita, e mesmo assim não é nativo), a solução mais elegante é o ActiveRecord do Rails, na minha opnião, você não se atem a detalhes da base, só se preocupa com detalhes do objeto, tratar os dados, não fica aquele monte de Anotações ou XML.
[/quote]
Creio que o problema não está em escrever os campos, e sim, realizar os mapeamentos ORM. Mesmo com o ActiveRecord, a aplicação continua sendo OO, e o banco relacional.
Um dos problemas que vejo no hibernate é que ele é incompleto e a forma de mapeamento é errada. Exemplo, quando mapeamos um relacionamento @OneToMany. Já definimos no mesmo lugar como é feito o mapeamento e como é feita a persistencia.
Os problemas disso são:
- A forma de mapear, e a forma de persistir, são duas coisas diferentes, logo não deveria estar tudo em apenas uma única anotação.
- O outro problema é que vc define a forma de persistir estaticamente, ou seja, vc só poderá usar essa forma de persistir. Se tiver duas situações no seu programa, o que é comum, onde em um lugar se deseja persistir de uma forma, e em outro lugar de outra forma dependendo da regra de negócio, não será possível.
Por isso sempre faço os mapeamentos não deixando o hibernate fazer nada de persistencia de forma automática, porque isso não funciona. Ao invés disso, executo códigos para persistir de acordo com a necessidade do meu sistema, quando for necessário. Acho que isso resolve alguns problemas que o vini citou…
[quote=MaiqueL][quote=Grinvon][quote=MaiqueL]Com relação a burocracia das ferramentas, eu penso o seguinte, o Hibernate por exemplo ele elimina da mão do programador muita coisa.
Existe burocracia pq existe muita complexidade a ser tratada.
Porém só temos o O/RM pq alguém não estava contente com a solução que existia na época. [/quote]
O hibernate não elimina a complexidade, ele elimina a “repetição de rotinas”, e só isso, a complexidade continua existindo, mesmo sendo de outra forma. O seu ponto tá certo![/quote]
sem comentários…[/quote]
Sinceramente, posso estar equivocado, mas entendi o seu comentário como crítica. Então eu queria saber em que ponto falei besteira?
De fato o hb/jpa ajuda e muito na crianção e manutenção das estruturas das tabelas, seja usando DDL ou MDL. Por tentar “simular” ORM, ele faz com que algumas coisas fiquem mais intuitivas, porém, a complexidade existe sim, só que agora ela tem outro nome.
Quem nunca teve problema com detached mode? Quem nunca tentou implementar um generic key no HB e conseguiu fazer funcionar muito bem de primeira, de segunda, de terceira…? Sabia que Listeners têm bugs que faz com que você não possa aproveitar uma sessão ativa neles e o JPA abafa o caso? Tendo que criar sempre sessões novas. E quando se fazia os joins, tentou fazer de forma bilateral para ver como ficava? A joça que você precisa fazer ao qual na estrutura “native” não tem esse problema. E coisas simples como o @OneToMany, onde o JPA dava pau na persistência de um elemento associado, ao qual a sua forma de salvá-lo deveria ser o adicionando exclusivamente na lista e persistinto a entidade mãe? Tudo bem que esse último aspecto não é um bug, mas limita a ação do desenvolvedor.
Agora a pergunta. Vale a pena usá-lo ao invés do tradicional modelo de JDBC como conhecemos? Sim. Por fatores que já foram mastigados em dezenas de tópicos aqui. Acredito que a solução hb/jpa é muito viável e é um framework com uma importância ultra.
Ainda não trabalhei com JPA 2.0. Li algumas artigos somente e vou fazer uso dele como teste, já que aqui no trabalho, não irei conseguir colocá-lo em prática por algum tempo.
E o meu conceito de framework segue a mesma lógica que a de miwi (ao menos no que entendi do que ela queria dizer). Um framework tem que ser simples para ser também chamado de framework e mesmo com a sua simplicidade, não poderá limitar as ações do desenvolvedor.
O Vini é um dos usuários mais bacanas aqui do forum, tem um tremendo bom senso e ajuda bastante quem precisa; sempre leio os post dele. Ele certamente achou que o artigo iria render uma boa discução e aprendizado, como de fato rendeu.
Porisso tenho certeza que ele sabia que a autora iria receber criticas positivas e tambem negativas pois muitos do forum “não passa a mão na cabeça” mesmo; claro que depende do que se escreve e como se escreve.
Para se atingir um nivel adiante é preciso saber receber criticas e aprender com elas, parabéns Vini por mais esta atitude espero que seja bem aproveitada.
Aos que gostam do Hibernate (eu me incluo), sejamos honestos, o framework é muito bacana mas se prestarmos atenção podemos perceber que é uma saida maluca para uma coisa que ainda não rolou - Não temos banco de dados orientado a objetos que tenha relevancia / credibilidade no mercado ainda.
Quando o banco de dados OO for uma realidade absoluta, iremos colocar estas coisas no fundo do baú e chama-las de GAMBI, tenho certeza disto.
P.S “Uma carta bem escrita e um código bem elaborado tem uma coisa em comum; a sintese” by eu mesmo.
flws
[quote=rogelgarcia][quote=Felagund]Em se falando de hibernate, temos um problema serio, como o Java é Tipificado, e não podemos criar campos em tempo de execução em uma classe (Sim, tem, mas ninguem é loco de ficar usando javassist a torto e adireita, e mesmo assim não é nativo), a solução mais elegante é o ActiveRecord do Rails, na minha opnião, você não se atem a detalhes da base, só se preocupa com detalhes do objeto, tratar os dados, não fica aquele monte de Anotações ou XML.
[/quote]
Creio que o problema não está em escrever os campos, e sim, realizar os mapeamentos ORM. Mesmo com o ActiveRecord, a aplicação continua sendo OO, e o banco relacional.
Um dos problemas que vejo no hibernate é que ele é incompleto e a forma de mapeamento é errada. Exemplo, quando mapeamos um relacionamento @OneToMany. Já definimos no mesmo lugar como é feito o mapeamento e como é feita a persistencia.
Os problemas disso são:
- A forma de mapear, e a forma de persistir, são duas coisas diferentes, logo não deveria estar tudo em apenas uma única anotação.
- O outro problema é que vc define a forma de persistir estaticamente, ou seja, vc só poderá usar essa forma de persistir. Se tiver duas situações no seu programa, o que é comum, onde em um lugar se deseja persistir de uma forma, e em outro lugar de outra forma dependendo da regra de negócio, não será possível.
Por isso sempre faço os mapeamentos não deixando o hibernate fazer nada de forma automática porque isso não funciona. Ao invés disso, executo códigos para persistir de acordo com a necessidade do meu sistema, quando for necessário. Acho que isso resolve alguns problemas que o vini citou…
[/quote]
Rogel,
acabou de me ocorrer que o ActiveRecord não é transparente, ele faz muita coisa por baixo dos panos, deixa mais agil, porém vc não faz ideia do que ocorre.
Seguindo a sua definição teriamos mais uma anotação, ou seja, mais uma configuração, cada vez mais complexo e trabalho, menos prático.
Você faz sua própria persistencia? Não utiliza o Hibernate? Acho que não compreendi muito bem o ultimo paragrafo.
[quote=Felagund]
Rogel,
acabou de me ocorrer que o ActiveRecord não é transparente, ele faz muita coisa por baixo dos panos, deixa mais agil, porém vc não faz ideia do que ocorre.
Seguindo a sua definição teriamos mais uma anotação, ou seja, mais uma configuração, cada vez mais complexo e trabalho, menos prático.
Você faz sua própria persistencia? Não utiliza o Hibernate? Acho que não compreendi muito bem o ultimo paragrafo.[/quote]
No caso, a ideia é que o mapeamento fosse genérico como citei no primeiro comentário, e houvesse uma forma de definir separadamente o que é mapeamento e o que é persistencia… Então poderia ser feito um alias, usando apenas uma anotação.
Mas seguindo a minha definição eu considero que nenhuma anotação é necessária.
package entity; //poderiamos definir que todas as classes do pacote entity são entidades
public class Pessoa {
private Integer id; //id será o PK da classe sempre
private Municipio municipio; // se municipio é outra entidade, é lógico que o relacionamento é ManyToOne
private List<Documento> documentos; //aqui é lógico que existe um relacionamento oneToMany
}Todas as informações estão na classe, logo nenhuma anotação deveria ser necessária.
Vc só usaria anotações para explicar algo que não fosse padrão, como um relacionamento mais complicado.
Eu considero também que a forma de persistir não deve ser definida estaticamente.
Exemplo:
@OneToMany(cascade=CascadeType.ALL, fetch=FetchType.EAGER)Se vc definir isso estaticamente, se houver duas situações diferentes no seu sistema, onde em uma não se deseja esse comportamento, voce terá um problema.
Na hora de carregar e salvar, é que deve ser indicado, se deseja ou não carregar ou persistir outras entidades. Isso não é referente ao mapeamento da classe, portanto nao deve estar em anotações na classe.
Eu uso o hibernate para fazer o mapeamento, mas não uso cascade ou fetch eager…
Se desejo carregar outro objeto na mesma query faço left outer join fetch
E para salvar listas tenho uma classe que faz isso pra mim, meu código fica mais ou menos assim:
save(pessoa)
.saveCollection("documentos")
[quote=fantomas][quote=miwi]
…
Fim do desabafo anti troll
[/quote]
O Vini é um dos usuários mais bacanas aqui do forum, tem um tremendo bom senso e ajuda bastante quem precisa; sempre leio os post dele. Ele certamente achou que o artigo iria render uma boa discução e aprendizado, como de fato rendeu.
Porisso tenho certeza que ele sabia que a autora iria receber criticas positivas e tambem negativas pois muitos do forum “não passa a mão na cabeça” mesmo; claro que depende do que se escreve e como se escreve.
Para se atingir um nivel adiante é preciso saber receber criticas e aprender com elas, parabéns Vini por mais esta atitude espero que seja bem aproveitada.
Aos que gostam do Hibernate (eu me incluo), sejamos honestos, o framework é muito bacana mas se prestarmos atenção podemos perceber que é uma saida maluca para uma coisa que ainda não rolou - Não temos banco de dados orientado a objetos que tenha relevancia / credibilidade no mercado ainda.
Quando o banco de dados OO for uma realidade absoluta, iremos colocar estas coisas no fundo do baú e chama-las de GAMBI, tenho certeza disto.
P.S “Uma carta bem escrita e um código bem elaborado tem uma coisa em comum; a sintese” by eu mesmo.
flws[/quote]
Hibernate não rolou? Achei que fosse o framework mais utilizado nas empresas…
Banco de dados OO é uma realidade. O unico problema é que a gambiarra é muito maior que no hibernate. Ferramentas ORM delegam toda a complexidade de gerenciar o banco de dados para o SGBD que estiver configurado. Banco de dados OO vc tem que implementar o seu próprio SGBD. E fazer isso usando locks de objeto é sujeito a soluções complexas e por isso propricio a bugs e performance inaceitável.
Oi mochuara,
Rolar, rolou; eu uso, gosto e no momento acredito ser a melhor resposta.
Mas aí é que está…só rolou porque não tem um banco de dados OO DE FATO talvez por conta do que você mesmo disse.
flws
Gostei dessa sua abordagem, seria realmente algo muito interessante de ser feito.
[quote=Felagund][quote=rogelgarcia]
Todas as informações estão na classe, logo nenhuma anotação deveria ser necessária.
[/quote]
Gostei dessa sua abordagem, seria realmente algo muito interessante de ser feito.[/quote]
O JPA já não faz isso?
Pelo que eu me lembro, se o atributo tiver o mesmo nome do campo na tabela não é preciso anotação.
Isso só não ocorre para a PK e os relacionamentos.
[quote=juliofsn][quote=Felagund][quote=rogelgarcia]
Todas as informações estão na classe, logo nenhuma anotação deveria ser necessária.
[/quote]
Gostei dessa sua abordagem, seria realmente algo muito interessante de ser feito.[/quote]
O JPA já não faz isso?
Pelo que eu me lembro, se o atributo tiver o mesmo nome do campo na tabela não é preciso anotação.
Isso só não ocorre para a PK e os relacionamentos.[/quote]
Não, precisa sempre ter a anotação.
Olá, já vou avisando que não li todos os posts.
Parabéns o Vini por postar o link do Blog e parabéns a miwi pelo Blog e pelo post propriamente dito (já coloquei ele no meu reader, apesar de não usar tanto o reader como eu gostaria…). Não ligue para os trolls, como o GUJ tem se tornado a cada dia uma comunidade cada vez maior, a proporção de sujeira (maus usuários, posts nonsense) também aumenta.
Minha opinião: eu concordo com a miwi. A gente demora um tempão para fazer as coisas funcionarem e ficamos totalmente amarrados aos malditos arquivos de configuração. Se é difícil usar, imagina escolher qual usar. Falaram de qualidade, que bibliotecas e/ou frameworks que foram feitos por pessoas experientes são melhores e tal, mas sei lá, parece que tudo é sempre um rolo danado. É indiscutível a utilidade do Hibernate e do Spring, mas ainda sinto que falta ser mais simples. De que forma? Não sei. E os frameworks MVC? Caóticos. E sempre um novo aparece que só insere mais uma forma de fazer a mesma coisa. Parece que sempre a gente ta usando um canhão para matar um mosquito.
Quanto a geração de código, eu sinceramente acho que nem vale a pena discutir. Quer usar algo que gere código? Use, mas não se importe com o que vai ser gerado. Reclamam de código de IDE (que é sujo mesmo haha), mas vocês já viram o código que o antlr gera? Haha aquilo sim é uma doideira. Não que um parser precise ser totalmente legível (o que importa é a gramática se legível), mas também não precisa ser um lixo 
Enfim, acho que essa é uma briga eterna, entretanto essas bibliotecas/frameworks/IDEs precisam melhorar sim. Pega alguém que usa todas as funcionalidades do Visual Studio ou Delphi por exemplo e manda fazer um cadastrinho em Java.
Meu post parece que ficou um pouco desconexo, mas acho que vocês conseguiram me entender 
[]´s
Ótimo tópico e ótimo post da garota, ainda não li todo o tópico , depois leio com mais calma, vou só dar meu pitaco rapidamente.
Não sou desenvolvedor Java e sim .Net, e apesar de .Net não ter tantos frameworks quanto Java, possui alguns, mas pelo que observo em .Net o pessoal ainda costuma utilizar mais soluções Ad Hoc, pelo menos aqui onde trabalho é assim, sempre escrevemos nossos DAO’s na mão, utilizando apenas o ADO.NET.
Até que o pessoal aqui resolveu desenvolver um framework, meu que cagada, agora estou em um projeto, totalmente engessado nesse framework, com mal uso de tudo, e tendo que dar voltas para resolver problemas simples.
Eu realmente acho que geradores automáticos de código deveriam gerar código não editável. Como no caso do Builder, Delphi ou VB, que gera um arquivo binário para a tela, e que o programador nem sequer pensa em descompilar aquilo para entender como ele faz.
Se a proposta é fazer automaticamente, então, faça direito.
Se estou tendo que mexer no código na mão depois disso, é porque meu gerador não cumpriu bem o papel dele.
[quote=ViniGodoy]Eu realmente acho que geradores automáticos de código deveriam gerar código não editável. Como no caso do Builder, Delphi ou VB, que gera um arquivo binário para a tela, e que o programador nem sequer pensa em descompilar aquilo para entender como ele faz.
Se a proposta é fazer automaticamente, então, faça direito.
Se estou tendo que mexer no código na mão depois disso, é porque meu gerador não cumpriu bem o papel dele.[/quote]
Concordo em número, genero e grau.
Claro, código gerado não deve ser modificado, mas as vezes a gente quer entender alguma coisa.
Concordo com o Vini que não deveria ser modificado.
Concordo plenamente com a autora do texto, que, aliás, escreve muito bem.
Assim que comecei a estudar o Java, eu achei a linguagem maravilhosa, e acabei me tornando o típico Java fan boy. Mas com o tempo, e principalmente com experiência em projetos reais, eu percebi que as coisas não eram tão fáceis como eu achava (e ainda acho) que deveriam ser.
Nessas situações nós tendemos a nos culpar, questionando a nossa inteligência ou aptidão para a o programação, e naturalmente eu também passei por esse processo. Mas novamente o tempo passa, e eu acabei percebendo que eu não era tão burro quanto imaginava, e que provavelmente o problema não estava comigo.
Digo isso porque eu acabei tendo contato com outras tecnologias, sendo que todas elas obviamente também possuem seus problemas, mas algumas delas me pareceram consideravelmente mais simples que o Java em aspectos que me importavam, como desenvolver facilmente uma aplicação Web que faça as operações básicas no banco de dados.
Sei que o que vou dizer nessa frase pode ativar o flag trollarComoSeNaoHouvesseAmanha de alguns usuários do GUJ, mas eu acho que utilizar o Java para Web foi uma das piores idéias de todos os tempos.
Hoje eu não gosto mais de programar com o Java, mas admito que a linguagem tem seus méritos. No entanto, me parece que o Java simplesmente não foi feito para a Web, e nem poderia, já que a Web estava engatinhado quando iniciou-se o desenvolvimento do Java.
Eu sempre vi o Java como uma versão mais segura e amigável do C++, mas assim como esse último, me parece que tentar aplicar o Java para desenvolvimento Web era tentar usar algo antiquado e verboso em um ambiente mais dinâmico. Dá pra fazer, assim como dá pra criar aplicações Web com C++, mas não me parece uma boa idéia.
Uma analogia que eu sempre tive na minha cabeça é que o Java é música clássica, e a Web é uma festa. Ou seja, os dois simplesmente não combinam.
Ainda que a plataforma tenha obtido bastante sucesso no desenvolvimento Web, eu credito esse sucesso ao poder que a Sun tinha no início da década passada. Se pararmos pra pensar imparcialmente, o que eu sei por experiência própria que é difícil quando estamos apaixonados por uma tecnologia, veremos que a imensa maioria das aplicações Web que desenvolvemos em Java poderiam ser desenvolvidas com outras tecnologias mais simples, como Ruby on Rails, PHP e Python. E sem perdas.
Eu sei que o lado troll do típico Java fan boy diria que essas tecnologias são “quick and dirty”, que são toscas, que tornam a manutenção um parto, que não escalam pra mais do que meia dúzia de usuários, entre outras idiotices que contamos a nós mesmos para nossa tecnologia preferida não parecer inadequada em um dado cenário. Eu sei disso porque eu já estive nessa posição, e disse e pensei coisas que hoje eu acredito serem incrivelmente idiotas.
Mas a realidade é que essas tecnologias são sim adequadas para a maioria das aplicações Web, e também são perfeitamente capazes de produzir código limpo, fácil de manter, e com uma suite de testes abrangente. Basta lembrar que a maioria dos sites mais populares da Web não têm no seu núcleo o Java, e sim o PHP (LAMP, sendo mais específico). Isso já prova, na mais cética das hipóteses, que o Java não inventou a escalabilidade, e que outras tecnologias podem sim ser aplicadas em sites com muitos milhões de pages views mensais.
Na verdade, é interessante notar que nesse sentido é o Java que tem que provar seu valor, já que dos sites mais populares, eu só me lembro do Linkedin e dos sites relacionados ao Google que possuem o Java como tecnologia base. Eu imagino que devem existir outros, mas é inegável que ele não é a tecnologia server side dominante na “Web pública”. Isso, ao meu ver, reforça o meu ponto de que o Java não foi feito para a Web, e que não é a melhor opção para a extrema maioria das aplicações Web. Caso contrário, porque tantos sites que deram tão certo passaram longe do Java. Desconhecimento? Duvido muito.
Outro ponto que me faz ver que o Java e a Web são opostos que não se atraem de forma nenhuma é o fato de que todo web designer que eu conheço odeia o Java, e acha que se trata da pior plataforma do mundo para a Web. E aqui eu não estou falando de pilotos de Photoshop/Fireworks, e sim de web designers de verdade, ou seja, pessoas que conhecem tudo sobre coisas como tipografia, teoria das cores e usabilidade, mas que também sabem mais sobre HTML/XHTML, CSS e JavaScript do que qualquer programador que eu já vi.
Esse tipo de profissional, cujo habitat natural é a Web, raramente se dá bem com o Java, pois se trata de uma tecnologia cujo feeling é muito diferente das tecnologias de base da Web. E olha que o melhor web designer que eu conheço sabia programar em C++, Objective-C, PHP e Ruby, mas ainda assim odiou o Java. Ou seja, a desculpa “odeia porque não conseguiu aprender” não é nem de longe válida aqui.
Aliás, esse argumento é péssimo sempre, além de ser um tiro no próprio pé. Se um número grande de desenvolvedores não consegue aprender uma tecnologia que deveria fazer algo comum como aplicações Web com CRUDs e relatórios, devemos, no mínimo, desconfiar que o problema está na tecnologia.
Enfim, o que estou tentando dizer aqui é que não foi exatamente a programação que se tornou mais complicada, e sim que a linguagem mais popular do mundo nos últimos anos possui uma visão mais burocrática do desenvolvimento de software. E por ser a linguagem dominante, essa complexidade atingiu inúmeros desenvolvedores, dando a impressão que desenvolver software hoje é mais difícil. E com isso foi-se embora o que pra mim é o fator mais importante: a diversão.