컨트롤러, 서비스 및 리포지토리 패턴에서 DTO를 사용하는 방법

컨트롤러, 서비스 및 리포지토리 패턴에서 DTO를 사용하는 방법 질문하다

1. 질문(문제점):

컨트롤러, 서비스 및 리포지토리 패턴을 따르고 있는데 DTO가 여기에 들어오는지 궁금합니다.

컨트롤러는 DTO만 수신해야 합니까? 내 이해는 외부 세계가 기본 도메인 모델에 대해 알기를 원하지 않는다는 것입니다.

도메인 모델에서 DTO로의 변환이 컨트롤러 또는 서비스 계층에서 발생해야 합니까?

2. 해결방안:

오늘날 Spring MVC 및 대화형 UI를 사용한 프로그래밍에서 웹 애플리케이션에는 실제로 4개의 계층이 있습니다.

• UI 레이어(웹 브라우저, JavaScript)

• MVC 컨트롤러, 즉 다음과 같이 어노테이션이 달린 Spring 구성 요소@Controller

• 서비스 계층, 즉 다음과 같이 어노테이션이 달린 Spring 구성요소@Service

• Data Access Layer, 즉 다음과 같이 어노테이션이 달린 Spring 구성요소@Repository

이러한 레이어 중 하나가 기본 레이어와 상호 작용할 때마다 레이어 간에 데이터를 전송하기 위해 일반적으로 POJO인 데이터를 송수신해야 합니다. 이러한 POJO는 데이터 전송 개체라고도 하는 DTO입니다.

레이어 간에는 DTO만 사용해야 하며 반드시 동일할 필요는 없습니다. 예를 들어 서비스 레이어는 데이터 액세스 레이어에서 받은 DTO에 비즈니스 로직을 적용할 수 있으므로 서비스 레이어 API의 DTO는 데이터 액세스 레이어 API와 다릅니다. 유사하게, 컨트롤러는 프레젠테이션(그룹화, 요약 등)을 준비하기 위해 데이터를 재정렬할 수 있으므로 웹 브라우저로 전송된 데이터는 서비스 계층에서 수신된 데이터와 다릅니다.

전체 추상화에서 데이터 액세스 계층의 API는 데이터 액세스 기술, 즉 JDBC, JPA, NoSQL, 웹 서비스 또는 기타 데이터 저장/검색 수단을 사용하는지 여부를 반영하지 않아야 합니다. 이것은 Entity 클래스가 데이터 액세스 계층 외부에 있으면 안 된다는 것을 의미합니다.

대부분의 프로젝트에는 해당 수준의 추상화가 필요하지 않으므로 DTO가 엔터티 클래스이고 데이터 액세스 계층에서 컨트롤러로 이동하는 것이 일반적입니다. JSON으로 인코딩된 웹 브라우저로 보냅니다.

프로젝트의 크기와 복잡성에 따라 다릅니다. 프로젝트가 커질수록 각 레이어를 가능한 추상화/독립형으로 만드는 것이 더 중요해집니다.

61303236