JPA를 사용하고 나서 @Builder를 쓰기 시작했는데 자세히 이게 무슨 역할을 하는지 몰랐었다.
그래서 오늘 간단하게 @Builder 어노테이션에 대해 정리를 해보려고 한다.
우선 JPA를 사용하고나서부터 패키지의 구조가 많이 변경됐다.
- Entity - DB 테이블과 1:1 매칭하는 클래스
- Repository - 해당 Entity에 대한 CRUD를 제공한다.
- Service - 기존에는 Service 인터페이스와 그걸 구현한 ServiceImpl 클래스를 만들었는데, JPA로 바꾸고 나서는 해당 Entity에 대한 클래스만 생성한다. Entity에 대한 비즈니스 로직을 수행한다.
- DTO - 클라이언트와 서버 간에 정보를 전송하기 위한 클래스다. Entity를 받아서 전송해도 되지만 문제점이 있다!
1. 클라이언트와 데이터베이스 사이에 결합도가 증가한다!
2. Entity는 테이블과 1:1 매칭되기 때문에 사용하지 않는 불필요한 정보까지 노출이 된다.
그래서 Entity로 받지 않고 필요한 정보들로 만든 DTO를 사용한다. - Controller - 클라이언트의 요청을 받고 응답을 보내주는 녀석!
나는 이렇게 구조를 만들어서 사용했다.
자 이제 @Builder가 어떤 마법을 부리는지 알아보자.
그러면 우선 간단하게 User Entity를 만들자.
@Getter @ToString
@Builer
public class User {
@Id
private String userId;
private String name;
private String email;
private int age;
생성자 생략..
}
총 5개의 정보를 받는 유저 Entity이다.
만약에 사용자한테 이름, 이메일, 나이만 정보를 받는다고 가정해 보자.
그러면 우리는 저 3개만 받는 DTO를 하나 설계해야 한다.
@Getter @Setter @ToString
public class UserDTO {
private String name;
private String email;
private int age;
생성자 생략..
public User toEntity(){
return User.builder()
.name(name)
.email(email)
.age(age).build();
}
자 처음 보는 메서드가 하나 있다.
바로 toEntity()라는 녀석인데 이 녀석은 처음에 컨트롤러에서 DTO를 만들면 생성자 때문에 받는 정보가 저장되는데,
나중에 그걸 이용해서 Entity로 바꿔주는 녀석이다.(물론 이름은 내가 지은거니깐 편하게 지어도 된다.)
자 우선 예시 코드는 이 정도로 간단하게 알아보고
그러면 @Builder는 대체 뭘 해주는 녀석이냐?
기존에는 DTO를 받아서 Entity로 변경시키려면
User user = new User();
user.setName("인딥");
user.setEmail("indeep@naver.com");
user.setAge(27);
유저 객체를 하나 만든 다음에
그 객체에 set을 이용해서 하나하나 값을 바꿔줘야 했다.
하지만!!!!
우리는 이전에 Entity에 @Setter를 위험해서 사용하지 않았다. (무결성을 위해서)
Setter가 없으니 DTO를 Entity로 바꿔주기 위해서는 생성자를 이용하거나 빌더를 이용해야 한다.
그때 빌더를 사용하면
public User toEntity(){
return User.builder()
.name(name)
.email(email)
.age(age).build();
이런 메서드를 통해서 깔끔하게 Entity로 바꿀 수 있는 것이다.
JPA를 사용할 때 다른 사람들의 코드를 많이 찾아보니
전부 @Builder를 사용하더라.
조금씩 알아가면 좋은 어노테이션이라고 생각한다.
2024.05.05 추가
지금 보니 빌더에 대한 사용법만 적어두고 짜잔 하고 있네...뭔가 싶네
사실 빌더라는 패턴을 굳이 사용하지 않아도 된다.
UserDTO userDTO = new UserDTO("test", "test@naver.com", "박기현", 15);
이렇게 그냥 DTO를 생성자를 이용해서 만들어주면 문제 없다. 그런데 왜 많은 사람들이 빌더 패턴을 이용할까?
위 코드를 보면 ID, 이메일, 이름, 나이 순서대로 데이터를 할당해줘야 한다. 하나라도 순서가 바뀌면 생성에 문제가 생긴다.
그 이유는? 생성자는 오버로딩이 가능해서 순서가 바뀐 여러 생성자를 만들 수 있기 때문에 저 순서가 중요해지는 것.
근데 빌더 패턴을 이용하면
1. 순서를 지키지 않아도 된다.
2. 가독성이 향상된다.
이 두 가지의 어마어마한 장점때문에 나도 애용하고 있는 편이다.
UserDTO build = UserDTO.builder()
.age(15)
.email("test@naver.com")
.name("박기현")
.id("test").build();
이게 같은 인스턴스를 생성하는 코드이다.
순서가 뒤죽박죽이어도 명시를 해놨기에 데이터가 문제 없이 할당되고, 또 어떤 데이터가 들어가는지 개발자가 한 눈에 알기 쉽다.
이러한 이유로 빌더 패턴을 많이 사용하는 것이다.
'스프링 개념' 카테고리의 다른 글
UsernamePasswordAuthenticationFilter는 어떤 필터인가? (0) | 2024.12.01 |
---|