[프로젝트] 넌 못 지나간다

가끔 유튜브나 트위치 방송 보면 도네로 보이는 유명한 밈인거 같아서 함 써봤다 (https://youtu.be/qrNzC5NWro0)

나는 절대로 포스팅 주제랑 관련 없는 제목은 들고 오지 않는다는 사실 내용을 보면 왜 이 제목을 썼는지 알게 될 것이에요 호호

🎱 DTO (Data Transfer Object)

DTO의 사전적인 의미는 '계층 간 데이터 교환을 위해 사용하는 객체' 이다.

여기서 말하는 계층은 Presentation Layer / Business Layer / Data Access Layer 정도로 알려져 있는데,

정말 단순화해서 보면 이는 각각 Controller / Service / Repository 를 의미한다고 보면 된다!

 

데이터는 엔티티에 담겨 있다. 그렇다면 엔티티를 계층마다 전달해가며 사용하면 되지 않을까? 정답은.. 안 된다! 🙁🙁

엔티티 클래스는  데이터베이스와 맞닿은 핵심 클래스 이다! 엔티티 클래스를 기준으로 테이블이 생성되고, 스키마가 변경된다.

 

엔티티 클래스를 웹 화면에서 바로 사용한다고 할 때, 요구사항이 복잡해지면 엔티티 클래스에 화면 처리를 위한 기능이 증가한다.

결과적으로 엔티티는 화면에 종속적으로 변하게 되고, 지저분해진 엔티티는 유지보수에 어려움이 생긴다.

또한 수많은 비즈니스 로직들은 엔티티를 기준으로 동작하기 때문에, 엔티티가 변경되면 여러 클래스에 영향을 끼친다.

 

결국 엔티티는  핵심 비즈니스 로직만 가지고 있어야 하고, 화면을 위한 로직을 처리하려면 DTO가 필요 하다.

설계할 때 좋은 방향은  View Layer와 DB Layer의 역할을 철저하게 분리하는 것 이다!

🪀 사용 범위에 대한 고민

그렇다면 DTO를 어떤 계층에서 사용하는 것이 좋을까? 일단 혼자서 생각해 본 내 생각을 말해보겠다.

Repository는 엔티티를 저장하는 계층이라고 생각한다. 따라서 이 곳에서는 엔티티 자체를 다뤄야하므로 여기서는 별로..?

 

한 계층 올라와서 생각해보자. Controller에서 DTO를 다루고, Repository에서는 순수한 엔티티를 다룬다고 하면,

Service가 중간에서 DTO → Entity 혹은 Entity → DTO 로 변환해주는 역할을 한다면? 이게 가장 깔끔하다고 생각한다!

 

플레이리스트 프로젝트에서 간단하게 DTO를 어떻게 사용했는지 그림을 그려보았다.

 

아티스트 등록 로직

1️⃣ Controller : SaveDto에 데이터를 받아서 Service로 넘김

2️⃣ Service : Repository에서는 Entity만 다루므로, DTO를 Entity로 매핑해서 Repository로 넘김

3️⃣ Repository : Entity 저장(save) 가능

 

아티스트 조회 로직

1️⃣ Repository : Entity 조회(find) 가능

2️⃣ Service : Repository에서 넘어온 Entity를 ResponseDto 객체를 생성하고 매핑해서 Controller로 반환

3️⃣ Controller : 웹 화면에서는 Entity가 보여지지 않고, ResponseDto에 담겨진 데이터가 보임

 

엔티티 자체는 절대 밖으로 꺼내지 않겠다는 굳은 마음 가짐이다..! ㅋㅋㅋㅋㅋㅋ

물론 Service 계층에서 필요에 따라 순수한 엔티티를 반환하는 로직도 있다! 몇몇 기능들을 수행하기 위해서!

하지만 중요한 건..? (꺾이지 않는 마음도 맞고) 웹 화면에서는 절대로 엔티티를 보여주지 말자! 🤗🤗