Minha proposta nesse cenário (Lazy “Homologation” Customer) é enviar para “homologação” e nesse período/gap de tempo, alguém que por ventura se interessar, já que o código é coletivo, fazer uma mágica chamada “Refatoração”, justificando assim o salário que se recebe religiosamente do contribuinte com algo que gere valor ao invés de ficar coçando…

O meu pensamento foi por essa linha.

quase comecei uma flamewar (how cool is that?) =)

rafael, tréplicas abaixo.
——————————————-
“E classes que representam o modelo do domínio não são lugares amplamentes conhecidos pela equipe? Se não for, então há grandes problemas!”

isso mesmo: pela *equipe*. mas se colocar em XML qualquer novato/cara de fora da equipe já saca logo como as coisas funcionam. é um mapa da sua aplicação (e pelo amor de deus, pessoal, que fobia é essa de xml? não tá escrito em japonês não.).
——————————————-
“Hoje em dia preocupação com compilação, geração de código, empacotamento, testes, deploy etc você deixa para uma ferramenta de integração contínua, existem várias no mercado, e se ainda assim você não quiser uma, um simples Ant resolve o teu problema.”

concordo parcialmente. nem sempre vc tem o script ali fácil na mão. em muitos casos ser capaz de só salvar um xml e restartar o servidor (se tanto) é muito prático. mas é um bom ponto.
——————————————-
“Acredite, ler 37 xml’s, ou até menos, é centenas de vezes MENOS legível e manutenível do que ler um domain model, mesmo em um modelo capenga.”

aqui deu deadlock =)
acho xml espetacular em termos e legibilidade… como eu disse antes, é um mapa da aplicação.
——————————————-
“DTO? Você realmente precisa disso? Andas trabalhando com aplicações distribuídas? Além do mais, mesmo em uma aplicação distribuída, você não precisa de um DTO para cada entidade do seu modelo.”

trabalho com rest diariamente, portanto preciso de TOs. mas rest é só um exemplo… não vejo como uma entidade substituiria um TO (a não ser como um wrapper inteligente em algo que deveria ser burro).
——————————————-
“A maioria dos frameworks/tecnologias te impulsionam a aprender novos conceitos ou até mesmo a abandonar velhos maus hábitos, isso é normal. E não deveria ser um problema para desenvolvedores.”

concordo. só esclarecendo que eu nunca insinuei que aprender coisas novas deveria ser um problema para desenvolvedores.
——————————————-
“Hoje temos vários frameworks (Spring, Guice etc) que cuidam disso para você, e o melhor, evitam o “glue code” na tua aplicação. Sem falar que estes mesmos frameworks tem uma excelente integração do iBatis, principalmente em relação a controle transacional.”

o spring é meu pão e minha manteiga =), e realmente ajuda *muito* na eliminação do boilerplate code (HibernateDAOTemplate é mão na roda).
——————————————-
“Anderson, eu conheço muito bem o iBatis pois já trabalhei muito tempo com ele, e sei bem suas diferenças em relaçao ao Hibernate/JPA, mas eu discordo de todos os teus argumentos em relação do Hibernate e os possíveis problemas que ele causa.

Na verdade vejo que você está um poquinho desatualizado em relação ao framework.”

Nem tanto… parei no Hibernate Core 3.2.x / Hibernate Tools 3.2b9, ou seja, menos de um ano de defasagem (tudo bem, isso é muito tempo em TI).

No fundo, acho que a melhor ferramenta é aquela à que você se adapta melhor. No meu caso, passei 4 anos +- felizes com o Hibernate, mas nosso relacionamente se desgastou =)

Estou namorando com o iBatis há pouco menos de 1 ano e tem sido fantástico. Não é só rápido. É ridiculamente rápido. E ridiculamente fácil.
——————————————-

Alfinetada final: anotações são o começo do fim. Vamos virar um exército de preguiçosos se isso pegar.

Abraços,
- Anderson

iBatis e Hibernate não possuem paradigmas diferentes, ambos são frameworks ORM, contudo o iBatis é um ORM com um filosofia baseada em DAOs, apenas isso.

E classes que representam o modelo do domínio não são lugares amplamentes conhecidos pela equipe? Se não for, então há grandes problemas!

* Mudou um parâmetro? Recompile o código e reempacote seu jar.”

Hoje em dia preocupação com compilação, geração de código, empacotamento, testes, deploy etc você deixa para uma ferramenta de integração contínua, existem várias no mercado, e se ainda assim você não quiser uma, um simples Ant resolve o teu problema.

“* Programador novo no projeto? Leia essas 37 classes para entender como as coisas funcionam.”

Acredite, ler 37 xml’s, ou até menos, é centenas de vezes MENOS legível e manutenível do que ler um domain model, mesmo em um modelo capenga.

“* Hibernate specific: ter uma entidade *e* um TO me parece um overkill. Sem anotações bastaria um TO, pois o hibernate o trataria como entidade sem poluir o TO original.”

DTO? Você realmente precisa disso? Andas trabalhando com aplicações distribuídas? Além do mais, mesmo em uma aplicação distribuída, você não precisa de um DTO para cada entidade do seu modelo.

“Ele te poupa do SQL mas em compensação te obriga a aprender um monte de outros conceitos.”

A maioria dos frameworks/tecnologias te impulsionam a aprender novos conceitos ou até mesmo a abandonar velhos maus hábitos, isso é normal. E não deveria ser um problema para desenvolvedores.

“Sessões são uma dor em especial. É ridículo ter que ficar colcando lógica no controlador/qqr outra classe para passar os objetos “do jeito que o Hibernate espera” (WTF??) para a camada de serviço.”

Hoje temos vários frameworks (Spring, Guice etc) que cuidam disso para você, e o melhor, evitam o “glue code” na tua aplicação. Sem falar que estes mesmos frameworks tem uma excelente integração do iBatis, principalmente em relação a controle transacional.

Anderson, eu conheço muito bem o iBatis pois já trabalhei muito tempo com ele, e sei bem suas diferenças em relaçao ao Hibernate/JPA, mas eu discordo de todos os teus argumentos em relação do Hibernate e os possíveis problemas que ele causa.

Na verdade vejo que você está um poquinho desatualizado em relação ao framework.

Enfim, discussões como estas são sempre bem vindas e agregam muito valor a todos.

Apesar dos dois frameworks possuirem paradigmas diferentes, essa “comparação” seria uma boa, me lembra um artigo na última MundoJava.

As configurações em XML são muito úteis na minha opinião (e tão boas para DRY quanto anotações).

Eu considero uma idéia terrível tirar as configurações de um local amplamente conhecido e escondê-las dentro de classes. Veja só alguns dos efeitos colaterais imediatos:

* Mudou um parâmetro? Recompile o código e reempacote seu jar.
* Programador novo no projeto? Leia essas 37 classes para entender como as coisas funcionam.
* Hibernate specific: ter uma entidade *e* um TO me parece um overkill. Sem anotações bastaria um TO, pois o hibernate o trataria como entidade sem poluir o TO original.

Quanto o iBatis ser uma piada de mau gosto, não concordo. É um *TIRO* para aprender e executar. Hibernate é leeeeeeeeeeento (apesar dos relatos em contrário do Gavin King) e muito mais difícil de configurar e usar. Ele te poupa do SQL mas em compensação te obriga a aprender um monte de outros conceitos. Sessões são uma dor em especial. É ridículo ter que ficar colcando lógica no controlador/qqr outra classe para passar os objetos “do jeito que o Hibernate espera” (WTF??) para a camada de serviço.

É isso… =)

Se você conseguir me convencer do contrário eu volto a usar o Hibernate =)

Abraços,
- Anderson