Dica Java: Evite poluir as entidades #004

As anotações do JPA (Java Persistence API) existem a milênios! Com a evolução dos frameworks, principalmente do Spring, e do próprio Java muitos recursos evoluíram junto. Por exemplo, em antigas versões para definir uma coluna em uma entidade (@Entity) era obrigatório anotar o atributo com @Column, se o padrão de colunas do banco fossem undercase era ainda necessário definir o nome da coluna. @Data @Entity public class Person { @Id //outros atributos @Column(name = "last_name") private String lastName; } Com o tempo houve uma evolução, já que por padrão as colunas eram undercase, apenas a anotação bastava para o de->para entre os padrões undercase e camelCase. @Data @Entity public class Person { @Id //outros atributos @Column private String lastName; } Atualmente basta adicionar o @Entity e todos os atributos são identificados automaticamente como referências a colunas, sendo obrigatório apenas a definição do @Id. @Data @Entity public class Person { @Id //outros atributos private String lastName; } Então torná-se implícito a definição das colunas, se fazendo desnecessário a anotação explícita. Isso faz a entidade ficar clean. Um adendo de dica, é na necessidade de anotar um atributo com @Column porém evitar ao máximo a definição dos argumentos na anotação, como no exemplo: @Column(nullable = false) Costumo orientar que essa responsabilidade não é da API (do mapeamento), essa responsabilidade é TOTALMENTE do banco de dados, é ele que deve definir tais regras da coluna, pois ele é que tem que garantir a estrutura e integridade dos dados, e NÃO a aplicação, afinal, ele pode ser consumido por outras aplicações, recursos e/ou frameworks. Fazer as definições por exemplo de nullable, insertable, e as demais, é ter a replicação da regra que deveria estar apenas no banco. Uma boa prática para o desenvolvedor, já que ele não terá essa informação na entidade, é analisar o banco (as tabelas) executando um explain para compreender a estrutura e as regras. É mais trabalhoso? Talvez, mas é o que acredito ser o mais correto pensando nas responsabilidades dos recursos.

Apr 15, 2025 - 01:00

Dica Java: Evite poluir as entidades #004

As anotações do JPA (Java Persistence API) existem a milênios! Com a evolução dos frameworks, principalmente do Spring, e do próprio Java muitos recursos evoluíram junto.

Por exemplo, em antigas versões para definir uma coluna em uma entidade (@Entity) era obrigatório anotar o atributo com @Column, se o padrão de colunas do banco fossem undercase era ainda necessário definir o nome da coluna.

@Data
@Entity
public class Person {

    @Id
    //outros atributos

    @Column(name = "last_name")
    private String lastName;
}

Com o tempo houve uma evolução, já que por padrão as colunas eram undercase, apenas a anotação bastava para o de->para entre os padrões undercase e camelCase.

@Data
@Entity
public class Person {

    @Id
    //outros atributos

    @Column
    private String lastName;
}

Atualmente basta adicionar o @Entity e todos os atributos são identificados automaticamente como referências a colunas, sendo obrigatório apenas a definição do @Id.

@Data
@Entity
public class Person {

    @Id
    //outros atributos

    private String lastName;
}

Então torná-se implícito a definição das colunas, se fazendo desnecessário a anotação explícita.

Isso faz a entidade ficar clean.

Um adendo de dica, é na necessidade de anotar um atributo com @Column porém evitar ao máximo a definição dos argumentos na anotação, como no exemplo:

@Column(nullable = false)

Costumo orientar que essa responsabilidade não é da API (do mapeamento), essa responsabilidade é TOTALMENTE do banco de dados, é ele que deve definir tais regras da coluna, pois ele é que tem que garantir a estrutura e integridade dos dados, e NÃO a aplicação, afinal, ele pode ser consumido por outras aplicações, recursos e/ou frameworks. Fazer as definições por exemplo de nullable, insertable, e as demais, é ter a replicação da regra que deveria estar apenas no banco.

Uma boa prática para o desenvolvedor, já que ele não terá essa informação na entidade, é analisar o banco (as tabelas) executando um explain para compreender a estrutura e as regras.

É mais trabalhoso? Talvez, mas é o que acredito ser o mais correto pensando nas responsabilidades dos recursos.