4. controller & service정리

1. 불필요한 Controller 및 Service 코드 제거

    - Default로 생성된 불필요한 코드 제거

 

 

2. Controller 및 Service 에서 사용할 DTO 정의

    - controller 의 DTO 와 service 의 DTO를 분리해보기!

    - prisma의 entity를 DTO로 변환해서 return

   

 

3. 2번의 작업을 하는이유!

    1) 책임의 분리 
        : Controller와 Service는 각기 다른 역할을 수행하는데, DTO를 분리하면 각 레이어가 서로의 책임을 명확히 할 수 있다.

    2) 유연성 및 확장성 
        : Controller와 Service에서 DTO를 분리하면, 특정 레이어에 변경이 생겼을 때 다른 레이어에 영향을 미치지 않도록 할 수 있다. 예시로, API의 응답 포맷을 변경하더라도 Service의 비즈니스 로직은 그대로 유지 가능! 각 레이어의 변경이 다른 레이어에 미치는 영향을 최소화하여, 유지보수성이 향상할 수 있다.

    3) API 계약 (API Contract) 정의
Controller에서 사용하는 DTO는 클라이언트와의 계약을 정의합니다. 클라이언트가 요구하는 데이터 형태나 구조를 정의하여, API의 일관성과 안정성을 높일 수 있고, Service에서 사용하는 DTO는 내부 로직이나 데이터 처리에 초점을 맞추기 때문에, 외부와의 계약보다는 비즈니스 규칙을 반영한 데이터 구조로 정의 됨. 이에 따라, 비즈니스 로직을 보다 명확하고 효율적으로 구현할 수 있다.

    4) 데이터 보호 및 정보 은닉 
        : Service에서 사용하는 DTO는 내부 데이터 구조를 반영하기 때문에, 외부에 노출되지 않아야 하는 필드를 포함할 수 있기 때문에 노출되지 않는 것이 좋다.

    5) 성능 최적화 
        : Controller에서 사용하는 DTO는 클라이언트에게 전달해야 하는 최소한의 데이터만 포함하는 것이 좋다. 불필요한 데이터 전송을 줄여 성능을 최적화하는 데 도움이 된다(request, response 응답 용량 감소 효과).

    6) DTO 변환 (DTO Transformation)
        : Prisma 엔티티를 DTO로 변환하는 이유는 데이터베이스의 엔티티 구조가 클라이언트와의 데이터 교환에 적합하지 않기 때문인데, Prisma에서 반환되는 엔티티는 주로 내부 데이터베이스 구조를 반영하는데, 이를 바로 API 응답으로 사용하면 불필요한 데이터나 구조적 차이가 있을 수 있다.