Ferramentas ORM são necessárias?

32 respostas
celso.martins

Estava a conversar com um amigo que é pós-graduado em Gerência de Projetos, formado pela PUC-RJ, sobre o Hibernate. Divagamos sobre a seguinte idéia: Precisamos fazer o mapeamento objeto-relacional em algum local, em XMLs (Hibernate) ou nas classes Java (com o padrão DAO).

Tendo em vista isso, qual seria a real necessidade de se utilizar uma ferramenta ORM? Me parece mais simples e relativamente tranquilo o mapeamento nas classes DAO.

Abraços,
Celso Martins

32 Respostas

rodrigoallemand

Não entendi… mapeando no DAO, em XML, com anotação no próprio POJO, em qualquer lugar que seja, não seria ummapeamento objeto relacional do mesmo jeito???

celso.martins

Sim, justamente.

Minha dúvida é se, por ser possível o mapeamento em DAO, os frameworks de mapeamento ORM são necessários. =)

É necessário aprender sobre o framework, as técnicas de mapeamento nos XMLs, etc. se você pode fazer tudo, simplesmente, nos DAOs?

R

pessoalmente gosto de orm quando o projeto é crud sem muitas querys complexas.

[]'s

maquiavelbona

Mais pessoas já se questionaram sobre isso:

http://www.theserverside.com/news/thread.tss?thread_id=40581
http://osdir.com/ml/programming.extreme-programming.databases.agile/2006-05/msg00031.html
http://www.logemann.org/day/archives/000150.html

E mais se procurares pela web.

Até!

rodrigoallemand

Rafaelprp:
pessoalmente gosto de orm quando o projeto é crud sem muitas querys complexas.

[]'s

Cabe a pessoa que está [modelando]/[arquitetando]/[desenvolvendo] esse sistema, mapear as coisas corretamente, se valer das boas práticas, de opniões de pessoas de fora, de third-parts boas e por ai vai!
Tenho sistemas bastante complexos utilizando hibernate e nada de errado acontece com eles. Basta vc saber usar direito o framework!

celso.martins

Gostei do segundo link. Estou a estudar XP nesse exato momento (espero que o diretor na empresa não entre no fórum!) =)

Eu também achei algumas opiniões a respeito. Entretanto gostaria de saber mais a opinião do pessoal Tupiniquim e, principalmente, do GUJ. Não encontrei essa discussão por aqui. Se existe, me digam por favor.

Dizem que o Brasil vai ser o maior país do mundo em produção de softwares. Então nada melhor do que a opinião de gente que faz por aqui. E faz bem feito!

Abraços!

rodrigoallemand

celso.martins:
Sim, justamente.

Minha dúvida é se, por ser possível o mapeamento em DAO, os frameworks de mapeamento ORM são necessários. =)

É necessário aprender sobre o framework, as técnicas de mapeamento nos XMLs, etc. se você pode fazer tudo, simplesmente, nos DAOs?

Quando vc fala “mapear dentro do DAO” seria algo como transformar um SQL com JDBC em objtos, correto?!?
Isso é muito relativo… sua equipe é melhor em SQL do que em Hibernate, tudo bem! Sua empresa não “homologou” o hibernate, tudo bem… acho que se o cenário muda, os atores tambem mudam!

T

vou ler os links depois com tempo. mas eu gosto de ORM simplesmente porque deixa o desenvolvimento mais simples e claro… Inclui muitas facilidades. Torno meu código mais OO assim.

celso.martins

rodrigoallemand:
Rafaelprp:
pessoalmente gosto de orm quando o projeto é crud sem muitas querys complexas.

[]'s

Cabe a pessoa que está [modelando]/[arquitetando]/[desenvolvendo] esse sistema, mapear as coisas corretamente, se valer das boas práticas, de opniões de pessoas de fora, de third-parts boas e por ai vai!
Tenho sistemas bastante complexos utilizando hibernate e nada de errado acontece com eles. Basta vc saber usar direito o framework!

Rodrigo, será que com DAO não funcionaria (e/ou ficaria tão claro - talvez até mais, por prescindir de XMLs)?

Você dfalou em saber usar direito o framework. A minha questão central é: Será que isso é necessário?

Abraços!

celso.martins

Por quê o DAO seria menos OO?

Abraços!

rodrigoallemand

Por quê o DAO seria menos OO?

Abraços!

Acho que a facilidade e o “mais OO” dito pelo amigo citado é pelo fato de vc não ter o SQL dentro do código…

R

rodrigoallemand:
Rafaelprp:
pessoalmente gosto de orm quando o projeto é crud sem muitas querys complexas.

[]'s

Cabe a pessoa que está [modelando]/[arquitetando]/[desenvolvendo] esse sistema, mapear as coisas corretamente, se valer das boas práticas, de opniões de pessoas de fora, de third-parts boas e por ai vai!
Tenho sistemas bastante complexos utilizando hibernate e nada de errado acontece com eles. Basta vc saber usar direito o framework!

pois é, mas 99% das vezes tenho q desenvolver projetos em bancos de dados legados q por si só já são complexos, não vejo ganho em adicionar mais complexidade de orm.

prefiro o Make It Simple Make It Better.

celso.martins

rodrigoallemand:
Rafaelprp:
pessoalmente gosto de orm quando o projeto é crud sem muitas querys complexas.

[]'s

Cabe a pessoa que está [modelando]/[arquitetando]/[desenvolvendo] esse sistema, mapear as coisas corretamente, se valer das boas práticas, de opniões de pessoas de fora, de third-parts boas e por ai vai!
Tenho sistemas bastante complexos utilizando hibernate e nada de errado acontece com eles. Basta vc saber usar direito o framework!

Esqueci na minha resposta de comentar a primeira parte de sua mensagem.

Acho essencial para um programador a captação de opiniões de terceiros e a tentativa de empregar boas práticas. Sem isso, creio eu, um programador está fadado a mediocridade!

Abraços!

celso.martins

Por quê o DAO seria menos OO?

Abraços!

Acho que a facilidade e o “mais OO” dito pelo amigo citado é pelo fato de vc não ter o SQL dentro do código…

Compreendo.

Mas será que a adição de complexidade, de diversos XMLs e o tempo desprendido com o aprendizado do framework compensam a não utilização de DAOs?

celso.martins

Rafaelprp:
rodrigoallemand:
Rafaelprp:
pessoalmente gosto de orm quando o projeto é crud sem muitas querys complexas.

[]'s

Cabe a pessoa que está [modelando]/[arquitetando]/[desenvolvendo] esse sistema, mapear as coisas corretamente, se valer das boas práticas, de opniões de pessoas de fora, de third-parts boas e por ai vai!
Tenho sistemas bastante complexos utilizando hibernate e nada de errado acontece com eles. Basta vc saber usar direito o framework!

pois é, mas 99% das vezes tenho q desenvolver projetos em bancos de dados legados q por si só já são complexos, não vejo ganho em adicionar mais complexidade de orm.

prefiro o Make It Simple Make It Better.

Concordo plenamente com você, não só com BD legado, mas com os criados por mim também.

R

quando o projeto é pensado do zero e o banco também do zero, aí são outros 500.

celso.martins

Nesse caso você recomenda um framework de ORM?

Por quê?

Abraços!

R

como falei, se for um crud sim, pq vc faz um simples mapeamento em xml ou annotations e a parada já “cria vida”.

operações com o banco ficam muito mais faceis.

rodrigoallemand

celso.martins:
Rafaelprp:
rodrigoallemand:
Rafaelprp:
pessoalmente gosto de orm quando o projeto é crud sem muitas querys complexas.

[]'s

Cabe a pessoa que está [modelando]/[arquitetando]/[desenvolvendo] esse sistema, mapear as coisas corretamente, se valer das boas práticas, de opniões de pessoas de fora, de third-parts boas e por ai vai!
Tenho sistemas bastante complexos utilizando hibernate e nada de errado acontece com eles. Basta vc saber usar direito o framework!

pois é, mas 99% das vezes tenho q desenvolver projetos em bancos de dados legados q por si só já são complexos, não vejo ganho em adicionar mais complexidade de orm.

prefiro o Make It Simple Make It Better.

Concordo plenamente com você, não só com BD legado, mas com os criados por mim também.

Infelizmente, para bancos legados a historia é diferente…
Mas, sem duvida, o conceito de ORM é muito bem vindo na comunidade. Eu sou a favor. Tenho uma ERP feita sobre Hibernate e estamos migrando para JPa, assim que a nova especificação do JPA sair.

Acho que a complexidade causada pelas configurações tentem a ser do mesmo nivel das colocadas em Statements processados em DTOs… cabe à equipe digerir essa complexidade. Hoje em dia, o complexo do ORM é suprido pelo conhecimento.

E sobre DAOs, isso é um conceito. Vc utiliza DAOs (ou Repositories) como quizer, com JDBC ou com Hibernate.

Mas, como cada um tem a sua preferencia…

ddduran

poxa quem ja teve que fazer na unha os daos conseguirem fazer isso:

Contato contato = dao.load(id);

Cliente cliente = contato.getUnidadeNegocio().getCliente();

e vir o cliente sabe por que ORM é necessario :slight_smile:

imagina ter que fazer um select pra puxar o contato, adicionar todos os relacionamento (talvez carregando com outros daos) e esses relacionamentos fazerem o mesmo…

lazy então é um sonho implementar, dentro de cada metodo get ter que carregar a entidade do banco… da até pesadelo só de lembrar

rodrigoallemand

Nem comento lazy loading…

pcalcado

A idéia por trás de uma biblioteca, seja de ORM ou qualquer outra coisa, é reaproveitar código. Eu poderia deixar de usar XYZ e fazer tudo sozinho mas o que isso vai agregar de valor ao meu sistema?

ORM é algo muito complexo que o Hibernate abstrai de tal maneira que eu considero o problema de impedance mismatch bem pouco relevante.

celso.martins

Com relação ao annotation, talvez você tenha razão. Preciso amadurecer mais as idéias sobre o caso.

Já estudei e usei o hibernate há cerca de 6 meses. Achei uma maravilha, a melhor coisa do mundo. Só que a criação de XML começou a ficar um saco. Até “entrar no sangue” os mapeamentos many-to-many e até o one-to-many, criar esses XMLs fica um saco. O mapeamento da herança, na minha opinião, também é um porre!

Não sei se é a opinião da maioria, mas criar/manter esses XMLs de mapeamento, na minha opinião, é muito chato! Gosto de XML para comunicar aplicações heterogêneas, não para mapear e configurar nada. =)

Creio que pelo fato de ter conseguido uma boa abstração nas minhas classes DAO (não é opinião minha, e acredito que posso melhorar muito essa abstração) eu esteja tão receoso quanto a verdadeira utilidade de um framework ORM. Certos pacotes eu aproveito inteiramente em vários projetos. Sem precisar mudar nada. Normalmente só altero a classe responsável pela conexão. Também é possível essa reutilização com os XMLs, mas como disse, acho manter isso um saco. Mas pode ser questão de costume.

Acho a curva de aprendizado para se aprender e “utilizar bem” um framework ORM também uma desvantagem. Vivemos numa época de prazos absurdos (pelo menos eu vivo e creio que a maioria dos desenvolvedores também) e na maioria das vezes não temos tempo para aprender a utilizar bem um framework.

Talvez seja melhor utilizar o tempo disponível para aprendizado aprendendo/aprimorando outros frameworks, como o Spring, e melhorando as nossas metodologias de desenvolvimento, para nos tornarmos o mais eficiente possível. Se aprofundar mais nos padrões de projeto também me parece essencial. Aprender padrões e, principalmente, utiliza-los de forma eficaz, não é algo tão simples, pelo menos para mim!

Abraços!
Celso Martins

celso.martins

rodrigoallemand:
celso.martins:
Rafaelprp:
rodrigoallemand:
Rafaelprp:
pessoalmente gosto de orm quando o projeto é crud sem muitas querys complexas.

[]'s

Cabe a pessoa que está [modelando]/[arquitetando]/[desenvolvendo] esse sistema, mapear as coisas corretamente, se valer das boas práticas, de opniões de pessoas de fora, de third-parts boas e por ai vai!
Tenho sistemas bastante complexos utilizando hibernate e nada de errado acontece com eles. Basta vc saber usar direito o framework!

pois é, mas 99% das vezes tenho q desenvolver projetos em bancos de dados legados q por si só já são complexos, não vejo ganho em adicionar mais complexidade de orm.

prefiro o Make It Simple Make It Better.

Concordo plenamente com você, não só com BD legado, mas com os criados por mim também.

Infelizmente, para bancos legados a historia é diferente…
Mas, sem duvida, o conceito de ORM é muito bem vindo na comunidade. Eu sou a favor. Tenho uma ERP feita sobre Hibernate e estamos migrando para JPa, assim que a nova especificação do JPA sair.

Acho que a complexidade causada pelas configurações tentem a ser do mesmo nivel das colocadas em Statements processados em DTOs… cabe à equipe digerir essa complexidade. Hoje em dia, o complexo do ORM é suprido pelo conhecimento.

E sobre DAOs, isso é um conceito. Vc utiliza DAOs (ou Repositories) como quizer, com JDBC ou com Hibernate.

Mas, como cada um tem a sua preferencia…

Sem dúvida, a idéia é o JDBC mesmo. Sei que o Hibernate usa DAOs. =)

Só não concordo com o nível de complexidade ser o mesmo. Acho um mapeamento em XML, como já disse, bem mais complexo que fazer esse mapeamento nas classes do projeto. Mas com falei, pode ser questão de costume!

Abraços!

celso.martins

ddduran:
poxa quem ja teve que fazer na unha os daos conseguirem fazer isso:

Contato contato = dao.load(id);

Cliente cliente = contato.getUnidadeNegocio().getCliente();

e vir o cliente sabe por que ORM é necessario :slight_smile:

imagina ter que fazer um select pra puxar o contato, adicionar todos os relacionamento (talvez carregando com outros daos) e esses relacionamentos fazerem o mesmo…

lazy então é um sonho implementar, dentro de cada metodo get ter que carregar a entidade do banco… da até pesadelo só de lembrar

Entendo, mas o cliente não vem num passe de mágica. Você precisou escrever isso em algum lugar! =)

Como disse anteriormente. Quando comecei a estudar o Hibernate, achei que era a 8ª maravilha do mundo. Mas aí comecei a divagar com esse amigo sobre a real necessidade de se mapear isso em XMLs, adicionando mais complexidade ao sistema.

Abraços!

Abraços!

celso.martins

pcalcado:
A idéia por trás de uma biblioteca, seja de ORM ou qualquer outra coisa, é reaproveitar código. Eu poderia deixar de usar XYZ e fazer tudo sozinho mas o que isso vai agregar de valor ao meu sistema?

ORM é algo muito complexo que o Hibernate abstrai de tal maneira que eu considero o problema de impedance mismatch bem pouco relevante.

Talvez você tenha razão. Vou dedicar esse fim de semana para tentar me aprofundar um pouco mais nessa questão. Vou travar um diálogo com alguns professores na faculdade sobre as idéias expostas aqui. Talvez o GUJ, os professores e mais algumas horas de estudo sobre o Hibernate me façam mudar de idéia. =)

Abraços!

pcalcado

Gente, Hibernate com XML? Usem metadados, estamos quase em 2008 já, XML é a exceção da exceção.

celso.martins

Qual livro você indicaria para o estudo melhor e mais aprofundado do Hibernate?

Tenho o Hibernate em Ação, mas o achei confuso e a tradução está um LIXO!! Já reclamei com a CM e me prometeram enviar outra edição. Já vai fazer aniversário! =(

Outra coisa, o que você (e a comunidade) acha do iBatis?

Estou de saída para a aula. Por volta das 22h15m já estarei em casa e poderei verificar as respostas!

Obrigado!

Abraços!

pcalcado

Eu sempre achei a documentação do Hibernate suficiente para quase todos os casos. O Hibernate in Action (não a tradução, por favor) tem alguns tratamentos para casos obscuros interessantes.

Eu acho o iBatis viável para um ambiente onde o modelo de dados é mais procedural que OO.

W

pcalcado wrote:
Eu acho o iBatis viável para um ambiente onde o modelo de dados é mais procedural que OO.

http://blog.fragmental.com.br/2006/08/24/bases-de-dados-sao-recursos/
O iBATIS seria ideal para aqueles bancos de dados normalizados/desnormalizados onde vc. tem que suar e gastar os dedos no SQL para não irritar o DBA e, aproveitar os recursos de SP e Triggers, Views, etc. em uma base legada.Ele é o ideal quando se tem as regras de negócio no SGBDs. Mais não esqueçamos que o iBATIs é um "Data Mapper framework " que armazena instruções SQL (não CRUD) em arquivos XML e atualmente usa Spring DAO, isso contraria a abordagem do que vem a ser realmente um ORM que gera instruções SQL automaticamente.

ddduran

celso.martins:
ddduran:
poxa quem ja teve que fazer na unha os daos conseguirem fazer isso:

Contato contato = dao.load(id);

Cliente cliente = contato.getUnidadeNegocio().getCliente();

e vir o cliente sabe por que ORM é necessario :slight_smile:

imagina ter que fazer um select pra puxar o contato, adicionar todos os relacionamento (talvez carregando com outros daos) e esses relacionamentos fazerem o mesmo…

lazy então é um sonho implementar, dentro de cada metodo get ter que carregar a entidade do banco… da até pesadelo só de lembrar

Entendo, mas o cliente não vem num passe de mágica. Você precisou escrever isso em algum lugar! =)

Como disse anteriormente. Quando comecei a estudar o Hibernate, achei que era a 8ª maravilha do mundo. Mas aí comecei a divagar com esse amigo sobre a real necessidade de se mapear isso em XMLs, adicionando mais complexidade ao sistema.

Abraços!

Abraços!

pou uma anotaçãozinha não é nada comparando com você implementar na unha ne?

olha um bom material disso
http://www.hibernate.org/hib_docs/annotations/reference/en/html_single/

celso.martins

ddduran:
celso.martins:
ddduran:
poxa quem ja teve que fazer na unha os daos conseguirem fazer isso:

Contato contato = dao.load(id);

Cliente cliente = contato.getUnidadeNegocio().getCliente();

e vir o cliente sabe por que ORM é necessario :slight_smile:

imagina ter que fazer um select pra puxar o contato, adicionar todos os relacionamento (talvez carregando com outros daos) e esses relacionamentos fazerem o mesmo…

lazy então é um sonho implementar, dentro de cada metodo get ter que carregar a entidade do banco… da até pesadelo só de lembrar

Entendo, mas o cliente não vem num passe de mágica. Você precisou escrever isso em algum lugar! =)

Como disse anteriormente. Quando comecei a estudar o Hibernate, achei que era a 8ª maravilha do mundo. Mas aí comecei a divagar com esse amigo sobre a real necessidade de se mapear isso em XMLs, adicionando mais complexidade ao sistema.

Abraços!

Abraços!

pou uma anotaçãozinha não é nada comparando com você implementar na unha ne?

olha um bom material disso
http://www.hibernate.org/hib_docs/annotations/reference/en/html_single/

Muito obrigado pela URL, já foi enviada para meu email pessoal e será degustada no feriado.

Acho que a discussão rendeu muitas opiniões interessantes e verdadeiras aulas. Agradeço a todos que se dispuseram a responder.

Abraços!

Criado 30 de outubro de 2007
Ultima resposta 31 de out. de 2007
Respostas 32
Participantes 8