왜 객체를 변환해야하나?

-잘못된 예-

//Controller
@RequestMapping(value = "/sign-up", method = RequestMethod.POST)
    public User signUp(@RequestBody User user) {
        return userService.signUp(user);
    }
    ...
//Service
	public String signUp(User user) {
        return userRepository.save(User user);
    }
    ...
    

로그인 할 때 받은 User 정보(객체)를 그냥 User로 쭉 넘겨주면 안될까? or User객체를 클라이언트에게 그대로 전달 해주면 안될까?

→ 안된다. 단점이 너무 많다. 이유를 알아보자.

문제점

• 불필요한 정보 포함으로 인한 보안 문제 → ex. ID만 필요하지만 Password까지 들고 옴
  
• 데이터가 늘어남에 따라 네트워크 비용이 올라감.
  → ex. 시스템 활용 데이터(생성, 수정일시) 포함
• 필요한 데이터가 포함되지 않을 수도 있다. → ex. 단순히 User객체의 정보만이 아닌 추가적으로 데이터가 필요한 경우 OR 연산이 필요한 데이터 필요할 때
  
• 계층 간의 전송(이동)시 데이터 변환 위험이 존재한다. → 원본(Entity)말고 사본(DTO)을 준다.
  → ex.[Controller↔Service↔Controller] 이동 시

  💡Entity & DTO
  Entity : 데이터베이스의 테이블과 매핑되는 클래스로 데이터 원본이다.
  DTO : 계층 간 데이터 전송을 위해 사용되는 객체로 아래 설명할 예정이다.

• 단일 책임의 원칙

1. client의 요청 값이 달라졌을때 DB까지 달라져야하나?

2. DB에 문제가 생겼을 때 Client가 알아야하나? (DB 컬럼 이름 바뀌면 클라이언트 호출 변경해야하나?)

   ⇒ 데이터를 옮기는 객체가 하나일 경우, 여러 계층에서 그 객체에 수정을 가하면 단일 책임의 원칙이 깨진다

💡Setter는 쓰면 안될까?
많은 사람들이 데이터가 변조 될 수 있기 때문에 Setter는 사용하지 말라하지만 반만 맞는 말이다.
간단한 예로 Setter를 안쓴다면 update는 못할것이다.
”쓰지 말라는 것이 아니라 남용하지말고 최소한으로 쓰자” 가 맞는 말이다.

Entity & DTO

Entity(Domain Object)

DB에서 가져온 데이터 원본 혹은 DB로 들어갈 연산이 끝난 원본이 될 객체.

💡 왜 Entity로 불릴까?
DB에서 객체를 Entity라고 부르는 데에서 유래 및 JDBC에서 쓰는 용어여서

DTO(Data Transfer Object)

계층 간 데이터 전송을 위해 사용되는 “데이터 전송 객체”으로 Entity의 사본이다.

어떻게 변환할까?

• CopyProperty (Setter + 생성자로 구현)
• Builder
• Setter
• 생성자
  를 사용하는 방법이 있다.

어디서 변환할까?

보통 Service에서 많이 변환하지만 필요에 따라 Controller, Repository에서 Entity<->DTO 변환을 할 수도 있다.

• Service에서 한다면
  1. MVC 모델로 나눈다면 Service와 Repository는 한 덩어리기에 Controller로 나가고 들어올 때 변환을 해준다.
  2. 로직 수행 후 가공된 데이터를 내보내는 것은 Service이기 때문에 Service에서 변환을 해준다.

     하지만 이렇게 된다면 Service가 가진 책임이 너무 커지기에 변환 로직은 DTO가 가져가게 한다.

• Controller
  Controller(A)가 여러 Service(A,B,C)들을 불러온다면 Service에서는 일관된 output을 내주고 DTO로의 변환은 각자의 Controller에서 해주는게 더 재사용성이 좋을 수도 있다.