Hibernate com configuração programática

Assuntos Gerais
#1

O pessoal do NHibernate (Hibernate for .Net) está incentivando o uso de configuração programática para os mappings do Hibernate ao invés de XML.

Fonte: http://www.infoq.com/news/2009/02/fluent-nhibernate-wiki

Estão trocando isso:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
namespace="QuickStart" assembly="QuickStart">
 
<class name="Cat" table="Cat">
<id name="Id">
<generator class="identity" />
</id>
 
<property name="Name">
<column name="Name" length="16" not-null="true" />
</property>
<property name="Sex" />
<many-to-one name="Mate" />
<bag name="Kittens">
<key column="mother_id"/>
<one-to-many class="Cat"/>
</bag>
</class>
</hibernate-mapping>

por isso:

public class CatMap : ClassMap  
{  
  public CatMap()  
  {  
    Id(x => x.Id);  
    Map(x => x.Name)  
      .WithLengthOf(16)  
      .Not.Nullable();  
    Map(x => x.Sex);  
    References(x => x.Mate);  
    HasMany(x => x.Kittens);  
  }  
}

Basicamente é usar uma fluent API da mesma maneira que o Mentawai suporta persistência via o MentaBeans:

        BeanConfig carro = bean(Carro.class, "Carros")
                .pk("id", DBTypes.AUTOINCREMENT)
                .field("name", DBTypes.STRING)
                .field("year", DBTypes.DATE)
                .field("motorId", "motor_id" /* = NAME IN THE DB */, DBTypes.INTEGER);
                
        BeanConfig motor = bean(Motor.class, "Motores")
                .pk("id", DBTypes.AUTOINCREMENT, "motor_id" /* = FK */)
                .field("name", DBTypes.STRING)
                .field("type", "industryType" /* = NAME IN THE DB */, DBTypes.INTEGER);
                
        BeanConfig peca = bean(Peca.class, "Pecas")
                .pk("id", DBTypes.AUTOINCREMENT, "peca_id" /* = FK */)
                .field("name", DBTypes.STRING);
                
        // configure bean relationships
        
        motor.join(Peca.class, "MotoresPecas"); // OneToMany relationship!

Quem agora será a boa alma que vai fazer isso (demonstrar, documentar e incentivar) a configuração programática para o Hibernate for Java?

#2

A idéia do Menta é muito boa. Enquanto os outros frameworks usam annotations, tudo é full Java. Boa pq não polui as classes com penca de anotações.

Como sempre digo: todo mundo amava XML e entupia os projetos de XML, então um dia alguém se revoltou e inventou as anotações. Agora poluimos nossas classes com anotações.

Com essa abordagem do Menta e, conforme você citou, de usar configuação do Hibernate em full Java mode é muito boa, pois usamos somente Java, que é o que fazemos melhor. Esse hibrido de XML + Java não agrada a mim também.

Mas não creio que essa idéia seja absorvida não. Dá bastante trabalho fazer isso. É bem mais simples anotar uma classe com @Entity e as propriedades com @Id (lembrando que apenas esses dois são obrigatórios).

#3

Ninguém.

Em Java mapeamentos são configurados com annotations, não faz sentido ter isso em “configuração programática”.

#4

[quote=Mauricio Linhares]Ninguém.

Em Java mapeamentos são configurados com annotations, não faz sentido ter isso em “configuração programática”.[/quote]

i++

Embora falam que Annotations polua o código Java, eu acho ela mais elegante que configuração programática (isso é minha opinião). Para mim, não seria vantagem alguma ter configuração programática já que temos annotations

#5

[quote=Jair Rillo Junior][quote=Mauricio Linhares]Ninguém.

Em Java mapeamentos são configurados com annotations, não faz sentido ter isso em “configuração programática”.[/quote]

i++

Embora falam que Annotations polua o código Java, eu acho ela mais elegante que configuração programática (isso é minha opinião). Para mim, não seria vantagem alguma ter configuração programática já que temos annotations[/quote]

Eu acho que para os casos simples onde vc só precisa de uma ou duas anotações para fazer isso eu concordo.

Agora quando a coisa fica mais complicada e vc começa a “poluir” o seu código com muita anotação eu prefiro configuração programática numa classe separada.

O Struts 2 tem exemplos de como o abuso de annotations pode deixar a coisa tão ruim ou pior do que XML: http://struts.apache.org/2.x/docs/validation-annotation.html

#6

Eu uso annotations, mas particularmente se houvesse uma maneira melhor eu usaria. Detesto poluir a entidade com essa pilha de anotações, mas isso é só uma questão pessoal.

#7

Saoj, somos da mesma opinião. Esse exemplo que você mandou é um dos exemplos onde trocamos a poluição do XML pela poluição das annotations.

Tenho um projeto aqui que uso praticamente o @Entity, @Id, @Column e os @Many-to-* ou @One-to-*. Uso o @Column apenas para visual, pois gosto de “saber” os campos anotados.

Porém se você usar Hibernate annotations + Hibernate Search + Hibernate Validator… seus POJOs vão ficar tão poluídos…

#8

Ai que está Sérgio. No caso do Struts 2 eu até concordo que muitas configurações podem realmente “sujar” o código, porém no caso do Hibernate (eu tenho usado ele por muito tempo e atualmente estou em um projeto bancário usando o Hibernate, com milhões de entidades, relacionamentos e etc) eu nunca passei por uma situação onde as annotations, de fato, poluiria o código.

#9

Sem contar que com annotations dentro da classe você sempre sabe quem é quem, quando a configuração fica fora, você tem que ficar indo e voltando pra saber o que está acontecendo e o que está ou não configurado.

Detesto ter informações sobre a mesma coisa espalhadas em lugares diferentes.

#10

Povo do NHibernate tá viajando grandão. Desde a primeira versão do .NET existe suporte a Attributes (Annotations no Java). Essa configuração programática é uma viagem só.

Rafael

#11

Eles devem saber que existe Attributes no .Net, mas mesmo assim prefiriram usar CÓDIGO para configurar e não mark-up.

Vejam só que bonito é a configuração programática: http://lobometal.wordpress.com/2009/05/08/eu-prefiro-programaticamente/

#12

Sério que você ainda está comparando o Mentawai com um framework que tem quase dez anos de idade?

As vezes eu fico aqui abestalhado olhando como todo mundo reclama do Struts 1.x mas TODOS fazem do mesmo jeito que ele fazia.

#13

Estou comparando com todos que não utilizam configuração programática. Um exemplo clássico de uma grande vantagem da configuração programáica é poder usar diretrizes como IF e FOR na configuração. Imagina que no Hibernate vc tem que configurar/mapear 30 campos (texto1, texto2, texto3, etc.) Um for programático resolve isso em duas linhas.

Vc diz todos os outros frameworks?

#14

Aí é que está, se você tem 30 campos de texto pra mapear e eles não tem nenhuma configuraçao especial, você não precia fazer nada, nem botar nenhuma annotation, tudo é configurado sozinho. Agora convenhamos, 30 campos de texto num único objeto é forçar a barra, não é não?

Todos os outros frameworks baseados em action fazem a mesma coisa que o Struts faz, só com um pouco mais de firula ou menos configuração. Mas a idéia básica continua sendo a mesma.

#15