Spring Boot의 매핑 모범 사례-java지도 시간-php.cn

Best Practices for Mapping in Spring Boot

Spring Boot 애플리케이션에서 DTO를 엔터티에 매핑하거나 그 반대로 매핑하는 모범 사례를 결정할 때 고려해야 할 몇 가지 핵심 요소가 있습니다: 단순성, 유지 관리 가능성, 성능 및 테스트 가능성. 각 방법에는 장점이 있으므로 모범 사례는 프로젝트 요구 사항에 따라 다릅니다. 다음은 다양한 접근 방식과 사용 시기를 분석한 것입니다.

1. <<와 같은 라이브러리를 사용하세요. 맵구조 >> (대형 프로젝트에 선호됨)

MapStruct는 DTO와 엔터티 간의 매핑 프로세스를 자동화하는 컴파일 타임 코드 생성기입니다.
최적의 용도: DTO와 엔터티가 많고 반복적인 수동 매핑 코드를 피하려는 대규모 프로젝트입니다.
MapStruct가 좋은 선택인 이유:

성능: 컴파일 타임에 매핑 코드를 생성하기 때문에 런타임 솔루션에 비해 매우 효율적입니다. 유형 안전성: 매핑이 올바르지 않거나 누락된 경우 컴파일 시간 오류가 발생하여 런타임 오류 가능성이 줄어듭니다.

유지관리성: 모든 상용구 코드를 생성하여 중복을 줄입니다.

사용자 지정 매핑 지원: 복잡한 필드(예: 다른 필드 이름, 중첩 개체)에 대한 사용자 지정 매핑을 쉽게 정의할 수 있습니다.

MapStruct를 사용하는 경우:

매핑할 DTO 및 엔터티가 많은 경우

성능이 중요한 경우(컴파일 시간에 생성되므로)

상용구 코드를 줄이면서 매핑에 대한 제어를 유지하고 싶은 경우.

public interface BaseMapper<D, E> {
    D toDto(E entity);
    E toEntity(D dto);
}

로그인 후 복사

@Mapper(componentModel = "spring")
public interface ClientMapper extends BaseMapper<ClientDTO, User> {
    // MapStruct will automatically inherit the methods from BaseMapper
}

로그인 후 복사

@Mapper(componentModel = "spring")
public interface SentimentMapper extends BaseMapper<SentimentDTO, Product> {
    // Inherits from BaseMapper
}

로그인 후 복사

다음과 같이 파일을 정리해야 합니다.

src
 └── main
     └── java
         └── com
             └── yourapp
                 ├── mapper                # Package for mappers
                 │    ├── BaseMapper.java  # Abstract base mapper
                 │    ├── ClientMapper.java # Client-specific mapper
                 │    └── SentimentMapper.java # Sentiment-specific mapper

로그인 후 복사

예: 서비스에서 매퍼를 사용하는 방법

package com.yourapp.service;

import com.yourapp.dto.UserDTO;
import com.yourapp.entity.User;
import com.yourapp.mapper.UserMapper;
import org.springframework.stereotype.Service;

@Service
public class ClientService {

    private final ClientMapper clientMapper;

    // Constructor injection (preferred method)
    public UserService(ClientMapper clientMapper) {
        this.clientMapper = clientMapper;
    }

    // Method to convert Client entity to ClientDTO
    public ClientDTO getClientDto(Client client) {
        return clientMapper.toDto(client);
    }

    // Method to convert ClientDTO to Client entity
    public User createClientFromDto(ClientDTO clientDTO) {
        return clientMapper.toEntity(clientDTO);
    }
}

로그인 후 복사

2. <<와 같은 라이브러리를 사용하세요. ModelMapper >> (빠른 동적 매핑용)

ModelMapper는 런타임 시 DTO와 엔터티 간의 필드를 동적으로 매핑합니다.
최적의 용도: 특히 프로토타입을 제작하거나 여러 필드에 대한 매핑 논리를 수동으로 작성하고 싶지 않을 때 빠른 설정이 가능합니다.
ModelMapper를 선택해야 하는 이유:

설정 용이성: 설정이 거의 필요하지 않으며 간단한 사용 사례에 적합합니다.

동적 매핑: 엔터티와 DTO의 구조가 비슷하고 개별 매핑 방법을 작성하고 싶지 않은 경우에 적합합니다.

예:

        ModelMapper modelMapper = new ModelMapper();
        ClientDTO clientDTO = modelMapper.map(client, ClientDTO.class);
        Client client = modelMapper.map(clientDTO, Client.class);

로그인 후 복사

ModelMapper를 사용하는 경우:

프로젝트가 중소 규모이고 개별 매퍼를 작성하고 싶지 않은 경우

DTO와 엔터티의 구조가 매우 유사하고 맞춤화가 많이 필요하지 않은 경우.

3. 수동 매핑(소규모 프로젝트 또는 특정 사례에 가장 적합)

수동 매핑에는 일반적으로 간단한 getter/setter 호출을 통해 변환 코드를 직접 작성하는 작업이 포함됩니다.
최적의 용도: 소규모 프로젝트, 간단한 매핑 또는 매핑 프로세스의 모든 측면을 완전히 제어해야 하는 경우.
수동 매핑이 좋은 선택인 이유:

간단한 매핑: 소수의 DTO와 엔터티만 있는 경우 수동 매핑이 간단하고 쉽게 구현될 수 있습니다.

전체 제어: 매핑이 수행되는 방식을 완벽하게 제어할 수 있으며 이는 매핑 중에 복잡한 논리나 데이터 변환이 있을 때 유용합니다.

예:

public class ClientMapper {
    public ClientDTO toDto(Client client) {
        ClientDTO clientDTO = new ClientDTO();
        clientDTO.setEmail(client.getEmail());
        return clientDTO;
    }

    public User toEntity(ClientDTO clientDTO) {
        Client client = new User();
        client.setEmail(clientDTO.getEmail());
        return client;
    }
}

로그인 후 복사

수동 매핑을 사용하는 경우: