Uso excessivo de annotations?

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

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:

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.

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?

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.

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

:shock: :shock: :shock:

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

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

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.

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

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

Uma coisa que seria legal era se o hibernate só exigisse o nome da coluna/tabela quando elas fossem diferente do nome do atributo/classe. Ex:

@Entity public class Pessoa{ private Integer id; private String nome; private Integer idade; //getters e setters }

E ele já saberia que o dito cujo teria que ir pra tabela pessoa e onde colocar cada atributinho.

E dá-lhe convention over configuration.

Mas já é assim.
Neste seu exemplo, se os nomes são os mesmos, só é necessário mais uma annotations a @Id e pronto.

Ex:

@Entity public class Pessoa{ @Id private Integer id; private String nome; private Integer idade; }

mauro_schneider:

Mas já é assim.
Neste seu exemplo, se os nomes são os mesmos, só é necessário mais uma annotations a @Id e pronto.

Ops :oops:
Acho que preciso dar uma lida melhor na documentação

mauro_schneider:

Mas já é assim.
Neste seu exemplo, se os nomes são os mesmos, só é necessário mais uma annotations a @Id e pronto.

Ex:

@Entity public class Pessoa{ @Id private Integer id; private String nome; private Integer idade; }

pq toda entidade mapeada pelo hibernate precosa de uma pk

Ideia: crie uma interface Environment, que define os getters pra todas as configuracoes (ou outras interfaces quen nao sao muito mais que bundles de configuracao).

Implemente essa interface: TestingEnvironment, DevelopmentEnvironment, UserAcceptanceTestingEnvironment, ProductionEnvironment, e os bundles especificos, caso necessario (InMemoryTestingDatabase, por exemplo). Basicamente, essa interface e as amigas dela contem toda a configuracao necessaria - de IoC a mappings do Hibernate a detalhes de JDBC, JNDI e o escambau.

Crie uma classe Application, com os metodos start(), isStarted() e stop(). Implemente essa interface pra todos os Environments.

Ponha uma main() nas implementacoes de Application apropriadas.

No projeto onde eu estava mes passado, a gente tinha um internet banking inteiro que subia meramente chamando a main() de DevelopmentEnvironment: Jetty, HSQLDB, simuladores dos mainframes e mais uns brinquedinhos, todos iniciados dali.

Nao eh soh se preocupar com configuracao, eh o deployment inteiro que precisa ser levado em conta