uso excessivo de annotations?

O que vocês acham que pode ser considerado uso excessivo de annotations?
Por exemplo desenvolver uma aplicação web sem tocat em XML apenas com:

@Bean para registrar beans no container IoC

@UrlMapping para dizer qual bean é responsavel por processar uma URL

@Entity para dizer que o bean é persistente (aqui ainda precisa configurar cada um no hibernate.cfg.xml)

@Transactional para dizer que o metodo em questão precisa de uma transação

Outras anotações do Hibernate para configurar os objetos persistentes
Com isto da pra fazer uma aplicação sem tocar em XML com exceção do hibernate.cfg.xml.
vocês acham que isto é uso excessivo de annotations? sera que estou resolvendo um problema e criando outro?

E anotações não são simplesmente pra retirar essas informações dos XMLs e colocar nas classes?

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

E anotações não são simplesmente pra retirar essas informações dos XMLs e colocar nas classes?

Sim, mas há certas vantagens. A anotação conta com informações adicionais, vindas daquilo que é anotado, como o tipo retornado por um método, por exemplo.

carneiro wrote:E anotações não são simplesmente pra retirar essas informações dos XMLs e colocar nas classes?

Sim, mas há certas vantagens. A anotação conta com informações adicionais, vindas daquilo que é anotado, como o tipo retornado por um método, por exemplo.

Nada diferente do que pode ser feito com XML. No XML do Hibernate você não precisa dizer qual o tipo de uma coluna, pelo tipo da propriedade no objeto ele sabe disso automaticamente. E o meu Eclipse não auto-completa anotações, isso é normal?

Annotations para marcar comportamento são sadias (transacional, requer privilégio X, persistível...) metadados com configuração (nome de tabela, usuário, datasource, senha...) são totalmente questionáveis IMHO.

pcalcado wrote:Annotations para marcar comportamento são sadias (transacional, requer privilégio X, persistível...) metadados com configuração (nome de tabela, usuário, datasource, senha...) são totalmente questionáveis IMHO.

Mas você não acha que dizer se um campo é "persistível" ou não e onde persistir ele não seria também uma funcionalidade da anotação?

Já que ela carrega informações sobre o código, eu acho que o nome da coluna lá no banco também seria parte do "código" dela. Ou não?

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

O que eu acho que não rola é as named querys ficarem em anotações... Se for assim, prefiro colocá-las diretamente nos métodos.

Acho que vou colocar em properties...

Acho que é o mesmo caso quando temos um "C:\Programa\dados" hardcoded no seu sistema. Lembro de um projeto que para rodar no Windows eu tive que criar diretórios c:\home, c:\opt, c:\usr ...

Eu acho que especificamente para esquema de dados o código deve ficar o mais longe possível deste, e para isso temos mapeadores como hibernate. Vincular o código de negócios com um esquema relacional qualquer é ptrender seu código a este esquema e agora que nós conseguimos nos livrar deste acoplamento voltar a tê-lo só para evitar um arquivo XML não me parece muito legal.

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

Então você prefere os hbm.xml às anotações?

Como falei, no caso de mapeamento O-R existem duas coisas distintas que são feitas pelo, por exemplo, Hibernate.

Uma é descrever a estrutura de uma classe em como vai ser persistida. Esta informação de Many-2-Many, Primary Key, etc. pode ficar no código (ainda que eu prefira um jeito mais leve de descrição não específico para Banco de Dados, a gente falou sobre isso aqui faz algum tempo).

Outra é configuração. Em que tabela, qual a URL do SGBD, qual a senha, otimizações, banco de dados utilizado, etc. Este deve ficar à parte do código do sistema.

O primeiro descreve objetos, normal que fique nos objetos. O segundo descreve configuração de uso de banco de dados, este tipo de configuração é dinâmico e não faz parte do código do negócio, além de ser uma informação pertencente à Camada de Persistência, não de Negócios.

Um DataMapper oferece um ponto único desta informação. Apenas um lugar no seu código, seja um DataMapper JDBC manual ou o framework configurado desta forma, deve contêr informação sobre como transformar classes em tabelas e isto nãod eve ficar misturado com regras de negócio.

Aí então o cara vai ficar com os dois? XMLs e anotações?

Eu prefiro ficar só com XML no caso do Hibernate

Lembro de um projeto que para rodar no Windows eu tive que criar diretórios c:\home, c:\opt, c:\usr ...

E eu q tive problemas com uma aplicação que tinha um proxy hard coded...

pcalcado wrote:Annotations para marcar comportamento são sadias (transacional, requer privilégio X, persistível...) metadados com configuração (nome de tabela, usuário, datasource, senha...) são totalmente questionáveis IMHO.

concordo com você, datasource, usuário, senha, ... não devem estar atrelados ao código fonte
só não acho que a tabela em que um objeto ai ser persistido, o nome do campo correspondente a uma coluna, qual é a PK da tabela, ... devam entrar no mesmo saco, ou seja, devam ser considerados o mesmo tipo de informações.
ainda mais que estas informações não são do tipo que muda durante o deploy de um sistema, assim como qual a URL de um controller/action/coloque aqui como o seu framework chama.
Ela é sempre a mesma dentro do contexto da aplicação.

então, este tipo de informação acho que não tem problema ser configurado com anotações, ja o qe pode ser alterado, ai sim vai pra um XML, properties, ...

não sei se estou separando os tipos de informação de forma errada, mas até o momento estou achando bastante confortavel de trabalhar assim

Maurício Linhares wrote:Aí então o cara vai ficar com os dois? XMLs e anotações?

Eu não vejo problemas em usar os dois, nessa separação de configurações que o Phillip falou fica interessante, pois você não tem aqueles xmls 'pesadões', e também permite o cara alterar algumas informações em run-time, através de xmls.

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

Síntese com destaque:
O problema é o excesso de configuração necessária, não onde a configuração mora.

SENDO ASSIM, prefiro deixar o código Java o mais livre de lixo possível, como o Shoes colocou.

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