DEV Community: Gregorio Santos

Entendendo o uso de record e DTO com java

Gregorio Santos — Mon, 13 Oct 2025 23:24:12 +0000

No ecossistema Java, os records surgiram como uma solução elegante para um problema antigo: a proliferação de código repetitivo (ou boilerplate). Antes dessa feature, classes simples, criadas apenas para transportar dados, como os famosos DTOs (Data Transfer Objects), exigiam uma implementação extensa e manual de métodos como equals(), hashCode() e toString(). Com a introdução dos records, essa implementação tornou-se significativamente mais concisa e eficiente, aumentando a produtividade e reduzindo erros.

O que é um record em Java?

É um tipo especial de classe, que são imutáveis por padrão e foi introduzida experimentalmente no java 14, tornando-se estável no java 16. Seu objetivo e simplificar a criação de classes que serve apenas para carregar dados.

O que é um DTO (Data Transfer Object)?

E um padrão de projeto, utilizado para não expor a camada de negocio da aplicação. E um objeto simples, contem apenas dados, utilizado para transportar dados entre camadas da aplicação e evitar a exposição de dados sensíveis.

Entendendo a estrutura de um record.

public record User(){}

public → pode ser acessado de qualquer lugar.
record → define que é um tipo record.
User → nome do record.

Exemplo de record com componentes:

public record User(String name, String email, LocalDate creationDate){
}

O compilador alem de gerar os métodos equals(), hashCode() e toString(), também gera os métodos getters name(), email() e creationDate() que são os componentes do record (equivalem a atributos de classes comum em java). Não gera setters, pois os dados em um record são considerados imutáveis.

Record como DTO (O CASAMENTO PERFEITO)

O exemplo a seguir apresenta uma comunicação simples, com o objetivo de transportar dados sem expor a classe de domino e utilizando a simplicidade do record.

Criando a classe de domínio User.

public class User {

    private String name;
    private String pass;
    private String email;
    private final LocalDate creationDate = LocalDate.now();
  //getter e setter

}

Criando nosso record, que vai representar DTO. Aqui protegeremos nossa senha(pass) de usuário, passando somente os componentes name, email e creationDate. Implementado um método estático (from) que vai retornar um novo UserDTO e recebera um User como parâmetro.

public record UserDTO(String name, String email, LocalDate creationDate){
  public static UserDTO from(User user) {
    return new UserDTO(
        user.getName(), 
        user.getEmail(), 
        user.getCreationDate());
    }
}

Como resultado temos:

public class Principal {

    public static void main(String[] args) {

        User user1 = new User("Joao","123","joao@mail");
        User user2 = new User("Jose","123","jose@mail");
        User user3 = new User("Maria","123","maria@mail");

        List<User> users = List.of(user1, user2, user3);

        User fidUser = users.get(2);

        UserDTO dto = UserDTO.from(fidUser);

        System.out.println(dto);

    }

}

Aqui simulamos nossa repositório de user, criamos três usuários, adicionamos eles a coleção de usuários utilizando List e simulamos a consulta de um usuário passando o index.

        User user1 = new User("Joao","123","joao@mail");
        User user2 = new User("Jose","123","jose@mail");
        User user3 = new User("Maria","123","maria@mail");

        List<User> users = List.of(user1, user2, user3);

        User fidUser = users.get(2);

Agora controlamos o que vai ser trafegado entre o nosso domínio e a camada de apresentação.

UserDTO dto = UserDTO.from(fidUser);

Utilizamos uma impressão simples no console para representar nossa camada de apresentação.

System.out.println(dto);

Retornando um UserDTO no console com name, email e dateCreation, protegemos assim nossa senha(pass) e protegendo nossa camada de domínio User.

UserDTO[name=Maria, email=maria@mail, creationDate=2025-10-12]

Entendendo @MappedSuperclass em JPA

Gregorio Santos — Sat, 24 Aug 2024 19:54:52 +0000

O JPA (Java Persistence API) fornece várias anotações para mapear classes Java para tabelas de banco de dados. Uma dessas anotações úteis é a @MappedSuperclass, que é usada para designar uma classe cujas propriedades devem ser herdadas por outras classes de entidade, mas que não é uma entidade em si. Vamos explorar a utilidade dessa anotação através de um exemplo prático envolvendo classes como Veiculo, Carro e Motocicleta.

O Que é @MappedSuperclass?

A anotação @MappedSuperclass é usada para indicar que uma classe não deve ser uma entidade independente, mas que seus atributos devem ser herdados por outras classes que são entidades. Isso é útil quando você deseja compartilhar atributos comuns entre várias entidades sem criar uma tabela separada para a classe base.

Principais características:

- A classe anotada com @MappedSuperclass não é uma entidade.
- Não é possível executar consultas diretamente na classe @MappedSuperclass.
- As subclasses que estendem a classe @MappedSuperclass são mapeadas para tabelas individuais no banco de dados, mas herdam os campos da classe base.

Exemplo Prático

Vamos criar um exemplo com uma hierarquia de classes para Veiculo, Carro e Motocicleta, onde Veiculo é a superclasse.

1. Classe Base: Veiculo

import javax.persistence.MappedSuperclass;

@MappedSuperclass
public abstract class Veiculo {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String marca;
    private String modelo;
    private int ano;

    // Getters e Setters

}

A classe Veiculo é anotada com @MappedSuperclass.
A classe Veiculo possui o campo id anotado com @id e @GeneratedValue. Este identificador único será herdado por todas as subclasses, garantindo que cada entidade derivada de Veiculo tenha um campo id.
Ela define três atributos comuns: marca, modelo e ano.

2. Subclasse: Carro

import javax.persistence.Entity;
import javax.persistence.Table;

@Entity
@Table(name = "carro")
public class Carro extends Veiculo {

    private int quantidadePortas;

    // Getters e Setters

}

A classe Carro herda os atributos da classe Veiculo.
Ela é anotada com @Entity e mapeada para uma tabela chamada carro.

3. Subclasse: Motocicleta

import javax.persistence.Entity;
import javax.persistence.Table;

@Entity
@Table(name = "motocicleta")
public class Motocicleta extends Veiculo {

    private boolean temSidecar;

    // Getters e Setters
}

A classe Motocicleta também herda os atributos da classe Veiculo.
Ela é anotada com @Entity e mapeada para uma tabela chamada motocicleta.

Mapeamento de Tabelas

Com as classes acima, o JPA criará as seguintes tabelas no banco de dados:

Tabela carro: Contém colunas para marca, modelo, ano e quantidadePortas.
Tabela motocicleta: Contém colunas para marca, modelo, ano e temSidecar.

A tabela Veiculo não existe no banco de dados, pois a classe Veiculo é apenas uma superclasse e não uma entidade.

Benefícios de usar @MappedSuperclass

Centralização do Identificador: O campo id é gerenciado na superclasse. Todas as entidades derivadas de Veiculo compartilham o mesmo esquema de identificação.
Reutilização de Código: Atributos comuns podem ser centralizados em uma superclasse, evitando duplicação nas subclasses.
Facilidade de Manutenção: Alterações em atributos comuns podem ser feitas em um único lugar.
Modelo de Dados Coeso: As subclasses compartilham a mesma estrutura, o que facilita a manipulação e o entendimento do modelo.

Considerações

Se você deseja que a superclasse também seja uma entidade (por exemplo, para consultas diretas), use a estratégia de herança @Inheritance em vez de @MappedSuperclass.
@MappedSuperclass é ideal para situações em que a classe base não precisa ser persistida como uma entidade individual, mas suas propriedades são relevantes para várias entidades.

Conclusão

A anotação @MappedSuperclass é uma ferramenta poderosa para criar hierarquias de classes reutilizáveis em JPA. No exemplo acima, conseguimos centralizar os atributos comuns em Veiculo e, ao mesmo tempo, manter a flexibilidade e a independência das entidades Carro e Motocicleta. Essa abordagem promove um design mais limpo e modular, especialmente em sistemas com múltiplas entidades que compartilham características semelhantes.