Annotations poluem o codigo?

Vejam essas classes:

@Entity( access = AccessType.FIELD )
@NamedQueries({
    @NamedQuery( name = "Page.containsLabel", 
        queryString = "" ),
    @NamedQuery( name = "Page.findByUser", 
        queryString = "" ),
    @NamedQuery( name = "Page.findRootPages", 
        queryString = "" ),
    @NamedQuery( name = "Page.findWatchedPages", 
        queryString = "" ),
    @NamedQuery( name = "Page.findHotPages", 
        queryString = "" ),
    @NamedQuery( name = "Page.findBookmarkedPages", 
        queryString = "" ),
    @NamedQuery( name = "Page.findByDate", 
        queryString = "" ), } )
@Filters( {
// a null status points out to a open page
@Filter( name = "Page.FilterDeleted", condition = "status is null" ) } )
@LuceneAnnotation
public class Page extends LiberEntity<Page> implements Identifiable<Long> {

@Id( generate = GeneratorType.AUTO )
    @Column( name = "page_id" )
    @LuceneId( luceneId = "PageId" )
    private Long id;

private int version;
    private int views;
    @LuceneField
    private Calendar date;
    @LuceneField( isContent = true )
    private String title;

@Type( type = "text" )
    @LuceneField( isContent = true )
    private String text;

@OneToMany( fetch = FetchType.LAZY,  mappedBy="page" )
    private Set<Comment> replies = new HashSet<Comment>();

@ManyToMany( fetch = FetchType.LAZY )
    @AssociationTable( 
        table = @Table( name = "pages_labels" ), 
        joinColumns = @JoinColumn( name = "fk_page_id" ), 
        inverseJoinColumns = @JoinColumn( name = "fk_label_id" ) )
    private Set<Label> labels = new HashSet<Label>();

@ManyToOne( targetEntity = "br.foo.bar.domain.User" )
    @JoinColumn( name = "fk_user_id" )
    private User author;

@ManyToMany( fetch = FetchType.LAZY )
    @AssociationTable( 
        table = @Table( name = "pages_watchers" ), 
        joinColumns = @JoinColumn( name = "fk_page_id" ), 
        inverseJoinColumns = @JoinColumn( name = "fk_user_id" ) )
    private Set<User> watchers = new HashSet<User>();

@ManyToMany( fetch = FetchType.LAZY )
    @AssociationTable( 
        table = @Table( name = "pages_bookmarkers" ), 
        joinColumns = @JoinColumn( name = "fk_page_id" ), 
        inverseJoinColumns = @JoinColumn( name = "fk_user_id" ) )
    private Set<User> bookmarkers = new HashSet<User>();

private String status;
    private boolean acceptHtml;

// gets, sets, bla bla bla

}

@Entity( access = AccessType.FIELD )
@NamedQueries({
    @NamedQuery( name = "User.findByRole", queryString = "" ),
    @NamedQuery( name = "User.findByGroup", queryString = "" ),
    @NamedQuery( name = "User.findByStatus", queryString = "" ),
    @NamedQuery( name = "User.findMoreActive", queryString = "" ),
    @NamedQuery( name = "User.findLessActive", queryString = "" ),
    @NamedQuery( name = "User.findByRegisterDate", queryString = "" ),
    @NamedQuery( name = "User.findByLastVisitDate", queryString = "" ),
    @NamedQuery( name = "User.findAbsenteeUsers", queryString = "" ),
    @NamedQuery( name = "User.findByEmail", 
        queryString = "select u from User u where u.email = ?" ),
    @NamedQuery( name = "User.findByLogin", 
        queryString = "select u from User u where u.login = ?" )
    }
)
public class User extends NextEntity<User> implements Identifiable<Long> {

@Id( generate = GeneratorType.AUTO )
    @Column( name = "user_id" )
    private Long id;

@Column( nullable = false )
    private String login;

@Column( nullable = false )
    private String password;

private String name;
    private String email;

@ManyToMany( 
        fetch = FetchType.LAZY, 
        targetEntity = "br.foo.bar.domain.Role" )
    @AssociationTable( 
        table = @Table( name = "users_roles" ), 
        joinColumns = @JoinColumn( name = "fk_user_id" ), 
        inverseJoinColumns = @JoinColumn( name = "fk_role_id" ) )
    private Set<Role> roles = new HashSet<Role>();

@ManyToMany( 
        fetch = FetchType.LAZY, 
        targetEntity = "br.foo.bar.domain.Group" )
    @AssociationTable( 
        table = @Table( name = "users_groups" ), 
        joinColumns = @JoinColumn( name = "fk_user_id" ), 
        inverseJoinColumns = @JoinColumn( name = "fk_group_id" ) )
    private Set<Group> groups = new HashSet<Group>();

@OneToOne( fetch = FetchType.LAZY )
    @JoinColumn( name = "fk_status_id", nullable = false )
    private Status status;

@Embedded
    @CompositeField(
        attributes={
            @LuceneField(attribute="signature"),
            @LuceneField(attribute="profile"),
        }
    )
    private SecondaryInfo info;

// gets, sets, bla bla bla

}

E algumas observações:
1. Acredito que depois de algum tempo, o Tiger se tornará padrão e annotations serão a maneira mais comumente usada para fazer o mapeamento com o Hibernate (e talvez outros concorrentes). Apesar de ser possivel mapear algumas classes com xml e outras com anotações, não me parece adequado misturar as duas coisas;
2. NamedQueries, as quais podem conter hql muito grandes, podem ser colocadas em um package-info, então, elas não necessariamente ficarão nas classes de dominio, o que alivia a quantidade de annotations nessas classes;
3. Em projetos maiores, outros conjuntos de annotations podem ser usados e a quantidade de metadados pode crescer um bocado;
4. Eu acho annotations um recurso extremamente util;

E a pergunta, annotations são muito verborágicas e deixam o codigo poluido? Ou falta apenas se acustumar com elas?

valeuz...

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4680 Offline

Hibernate precisa de muita configuração. Já que há ferramentas para gerá-la quase toda para você, qual o problema de deixar no coitado do XML?

Código azul fede

Pode nao ter caido minha ficha ainda, mas acho isso um retrocesso. Primeiro faziamos tudo no codigo com numeros magicos. Depois foram movidos pra constantes. Depois extraiu-se as configuracoes relevantes para properties/XML/TXT/[qualquer coisa que nao seja compilado no codigo].

Nessa ultima etapa perdeu-se os recursos de verificacao em tempo de compilacao - mas a flexibilidade de poder alterar as configuracoes sem recompilar o codigo vale a pena na maioria dos casos.

Agora as anotacoes parecem querer trazer as coisas para o codigo, misturando configuracao e codigo e ainda perdendo a capacidade de deteccao de erros em tempo de compilacao (isso talvez seja contornavel).

Oras, o que eh de configuracao "complicada" (isso eh discutivel), como EJBs, Hibernate, etc, vai continuar sendo complicado, exceto se arrumarem um jeito "magico" de fazer a coisa - e esse jeito, IMHO, nao se resume a simplesmente mover as configuracoes de um lugar para outro.

Eh isso ai - desculpem se nao entendi o "espirito" das anotacoes e viajei na maionese.

Marcio Kuchma

kuchma wrote:Pode nao ter caido minha ficha ainda, mas acho isso um retrocesso. Primeiro faziamos tudo no codigo com numeros magicos. Depois foram movidos pra constantes. Depois extraiu-se as configuracoes relevantes para properties/XML/TXT/[qualquer coisa que nao seja compilado no codigo].

Nessa ultima etapa perdeu-se os recursos de verificacao em tempo de compilacao - mas a flexibilidade de poder alterar as configuracoes sem recompilar o codigo vale a pena na maioria dos casos.

Agora as anotacoes parecem querer trazer as coisas para o codigo, misturando configuracao e codigo e ainda perdendo a capacidade de deteccao de erros em tempo de compilacao (isso talvez seja contornavel).

Oras, o que eh de configuracao "complicada" (isso eh discutivel), como EJBs, Hibernate, etc, vai continuar sendo complicado, exceto se arrumarem um jeito "magico" de fazer a coisa - e esse jeito, IMHO, nao se resume a simplesmente mover as configuracoes de um lugar para outro.

Eh isso ai - desculpem se nao entendi o "espirito" das anotacoes e viajei na maionese.

Marcio Kuchma

A questão é que Anotações são menos verbosas que XML. Mas eu acho que seria muito melhor criar uma linguagem específica para fazer configurações. Groovy talvez seja a solução. Ou pelo menos ao invés de fazer assim:

fazer algo assim...

vamorim wrote:
<bla> <ble> abc </ble> </bla>

fazer algo assim...

bla { ble { abc } }

Para mim é a mesma coisa.

kuchma, dá para fazer verificações em tempo de compilação sim, quer dizer, de que possiveis verificações vc está falando? Bom, isso não me parece ser uma bronca. Mas concordo com o fato de que algumas configurações ficam melhor fora do codigo.

vamorim, criar uma linguagem parece menos coerente do que alterar a sintaxe das anotações, não? Outra linguagem é meio overkill.

valeuz...

This message was edited 1 time. Last update was at 06/07/2005 19:10:29

danieldestro wrote:

vamorim wrote:
<bla> <ble> abc </ble> </bla>

fazer algo assim...

bla { ble { abc } }

Para mim é a mesma coisa.

Não reparou que o segundo é bem menos verboso?

Contando apenas os caracteres não-brancos temos 25 no primeiro e 13 no segundo. Ou seja uma economia de 50%.

Imagina a diferença em larga escala. Um arquivo XML de 1000 linhas por exemplo... Dá uma baita diferença na legibilidade...

This message was edited 1 time. Last update was at 06/07/2005 19:31:15

Eu, o Vinci e um pessoal da PUC-RIo que esqueci infelizmente o nome tivemos uma conversa sobre isso na rodoviaria, voltando do STD.

Anotaçoes sao legais para MARCAR, nao para configurar. Por exemplo, voce deveria fazer algo assim (pseudocodigo):

E ter um outro lugar configurado que metodos marcados com @myTag sao logados, num XML, aspecto, properties, a la Mentawai ou qualquer outra coisa.

Agora fazer:

Cai no que o kuchma falou.

Complementando, annotations para mim sao como Serializable (tagging interfaces) feitos de maneira menos gambiarra

Nossa, que código engraçado. É Java?

Falando sério, annotations são bem legais para aquilo que o Shoes falou. Fora isso, dá vontade de chorar

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Eu uso annotations nos meus posts

@+ para indicar os editados como este

@+ escroto

Thread.start() Membro desde: 12/07/2005 12:46:51 Mensagens: 32 Offline

As anotações do hibernate são uma alternativa pros XML ...

eu não gosto mto de XML, certa vez escutei "Quando foi que desenvolver em java foi criar arquivos XML?" ....

XML é uma boa saida, melhor q os properties ....

porem acho estranho ter a mesma quantidade XML que a de seus Beans ...

tudo bem, obvio .... mas bem, acho muito feio ....

as anotações ao meu ver trocam o problema de configurações de lugar ...
ao menos fica tudo consentrado e por mais q esteja poluido, fica mais facil de encontrar aonde você quer mudar .... exitem formas de diminuir as anotações e eu prefiro deixar o accessfield p/ property e deixar nos gets...

dessa forma quando você quer apenas visualizar a classe, fica mais legivel...

em fim ... configurações são um problema complicado ...

por mais q o hibernate3 tenha ajudado um pouco é um problema sem grandes soluções ...

as soluções são sempre a de trocar o problema de lugar ...
cabe a cada um decidir aonde vai querer ir quando tiver q resolver um problema ....

JavaEvangelist Membro desde: 07/04/2005 11:37:42 Mensagens: 328 Offline

Sinceramente, acho um lixo encher o seu dao dessas anotações.

Gente, qual é o bixo de 7 cabeças em criar xml's? E se é assim, por que não usar ferramentas que gerar o xml?

E como se os xmls do hibernate fossem tão complicados!

carneiro wrote:Sinceramente, acho um lixo encher o seu dao dessas anotações.

Erhm, não é nos DAO's e sim nas classes de dominio! Eu gostei de anotações porque já estava bastante acostumado com XDoclet que, para novos sistemas, parece-me a abordagem mais apropriada. Claro que existem diferenças entre XDoclet e anotações, mas o proposito é o mesmo. Quanto a usar property access ao inves de field access, não acho que faça muita diferença não.

valeuz...

JavaEvangelist Membro desde: 07/04/2005 11:37:42 Mensagens: 328 Offline

jack_-_ganzha,

ooops, não prestei muita atenção. Mas, de qualquer forma, não acho que anotações caiam bem para gerar os xmls do hibernate.

Bem, apenas uma opiniao...

Valeu!

Cara, aquela classe tem mais annotations do que código Java

Unghn!

Notícias, artigos e o maior fórum brasileiro sobre Java