MVC패턴
MVC 패턴은 어플리케이션을 Model/View/Controller 3가지로 분리하는 패턴이다. Model에서는 비지니스 로직을 처리하고, View에서는 화면을 뿌려준다. Controller는 Model과 View 사이의 연결을 담당해준다.
DTO
레이어드 아키테겨에서 우리는 Controller, Service, Repository 3계층을 활용하여 스프링 MVC를 구현한다. Domain객체는 DB에 데이터를 넣거나, 가져올 때 사용하는 객체이고, 계층간의 데이터 전송은 Dto(Data Transfer Object)로 변환 후 진행한다. Dto는 계층간 데이터 교환을 위해서 사용하는 객체다.
변환해야하는 이유?
Dto를 사용하지 않고 Domain을 직접 사용할 경우 문제점이 있다.
1. Domain의 구조가 클라이언트에게 노출된다.
2. 실제 프로젝트를 구현하면 API에서 필요한 데이터만을 요청하는데 Domain 객체를 사용하면 불필요한 데이터까지 전부 넘어올 수 있다.
Dto의 반환 위치?
프로젝트를 시작하기 전, Domain의 객체를 어디서 DTO로 변환해야 하는지에 대한 팀원들간의 상의가 있었다.
1. Repository
Repository는 DB에 직접 접근하여 데이터를 관리하는 레이어다. Entity를 관리하는 것이 주역할이기 때문에 적합하지 않다고 생각했다.
2. Controller
Controller에는 Dto가 무조건 있다. 하지만 Entity도 있어야하나? 라는 생각에 Entity를 Controller까지 반환해서 굳이 Controller에 사용하지도 않는 Domain객체를 노출시킬 필요가 있나 하는 의문이 있었다. Domain이 Controller까지 노출되면 Domain의 변경위험이 Controller에도 존재하는 게 걸렸다.
3. Service
Service레이어는 비즈니스 로직을 처리하는 곳이고 Dto 변환도 비즈니스 로직의 일부라 생각하기 때문에 Domain객체를 Service까지 노출시키고 Dto객체의 변환을 Service레이어에서 진행하기로 했다.
(+)이견 : Service레이어에 Dto가 안들어 온다면 여러 종류의 컨트롤러에서 해당 서비스를 사용할 수 있는 장점이 있고 Dto가 Service계층까지 들어올 수 있다면 도메인으로 변환을 초기에 하지 않는다면 Repository까지도 들어올 수 있다는 단점이 있다. 라는 생각으로 컨트롤러에서 Dto로 변환한다고 하셨다.
