Mapper로 파라미터 전달하는 방법의 장단점(DTO,@Param,Map)

MyBatis를 사용하면서 2개 이상의 파라미터를 전달해야 할 때, 사용하는 방법은 주로 Map을 사용해서 전달했다.

하지만, Map 방식보다는 DTO가 더 좋은? 방식이라고 들었다. 그래서 오늘은 Mapper로 파라미터를 전달하는 방법이 무엇이 있으며 어떤 장단점들이 있는지 알아보려고 한다.

---

1. DTO (Data Transfer Object)

장점

• 요청에 필요한 객체를 만들어 프로그램에 적절하게 사용 가능
• 객체 내 필드의 유효성 검사를 엄격하게 진행 가능
• 가독성
• 관심사 분리

단점

• 코드 중복 : 도메인 객체와 DTO 사이에 매핑을 수행해야 하므로 코드중복 발생 우려.
• 네트워크 오버헤드 : 객체 간 데이터 전달이 필요하므로 네트워크 오버헤드가 발생할 수 있다.

사용이 적합한 경우

• 복잡한 쿼리나 여러 개의 파라미터가 필요한 경우, 매핑 작업이 비교적 단순한 경우, 타입 안정성을 보장해야 하는 경우

DTO는 계층 간 이동(Controller <-> Service) 뿐만 아니라, 요청(Request -> Controller)에도 사용이 된다.
계층 간 이동시에는 로직을 가지고 있지 않은 순수한 데이터 객체로, 불변성을 유지하기 위해  Setter 사용을 지양한다.
요청에 필요한 DTO는 Builder 패턴을 이용하여 Entity로 변환하는 경우가 많다.

*Entity : DB와 맞닿는 핵심 클래스이며, Entity를 기준으로 테이블이 생성되고 스키마가 변경된다.
*Entity를 직접적으로 사용하게 된다면 원치 않게 Entity의 속성을 변경시킬 위험이 존재하며, 불필요하게 외부에 노출될 가능성이 있기에 DTO를 사용한다.

---

2. @Param

DB에 다수의 파라미터를 전달할 때는 전달되는 변수들에 @Param 어노테이션을 붙여주어 각 변수를 구분할 수 있도록 해준다. 변수를 한 개만 전달할 때는 상관없지만, 2개 이상이면 반드시 써주는 게 좋다.

 

장점

• 명시적인 파라미터 매핑
• 동일한 파라미터 이름 중복 방지
• 복잡한 쿼리에서 유용

 

단점

• 불필요한 추가코드 필요
• 파라미터 변경 시 수정필요
• Java 메서드 시그니처와 일치필요

* 메서드 시그니처 : 메서드를 정의할 때 사용되는 메서드의 식별정보를 나타내는 부분으로서, 메서드 이름, 파라미터 타입, 파라미터 순서, 리턴 타입으로 구성된다.

 

사용이 적합한 경우

• 단순한 쿼리나 몇 개의 파라미터만 필요한 경우, 메서드 시그니처에서 파라미터 이름을 사용하고 싶지 않은 경우

---

3. Map

장점

• 유연한 데이터 전달
• 동적 쿼리 생성
• 간단함

 

단점

• 타입 안정성 부족
• 가독성 저하
• 매핑작업 필요
• 리팩토링 어려움
• 의미 없는 키 사용 가능성

사용이 적합한 경우

• 매우 동적인 쿼리를 다루거나 여러 타입의 파라미터를 유연하게 전달해야 하는 경우

---

각 방법마다 장단점이 있다. 어떤 방법을 사용할지는 상황과 요구사항에 따라 맞게 사용하면 될 것 같다.

 

그래도 요즘에는 보다 객체지향적이고 안전한 방식을 선호함으로써 주로 DTO 방식을 많이 사용한다.

필요한 데이터만 캡슐화하여 전달하므로 데이터 노출에도 최소화하면서도 코드의 가동성과 유지보수성을 높일 수 있다.