# Spring - MyBatis 구조

원래 학원에서 boot로 Spring을 배워서

나는 Spring boot + jpa + mariaDB + 타임리프 or 리액트를 사용했어서

mvc 패턴을 만들 때

controller + dto + entity + repository + service 로 구조를 잡았는데..

회사에와서 Spring mvc 구조로 개발을 하게되었따.

매우 당황스럽고 뭐가 뭔지 모르겠었지만 이제 어찌저찌 쪼끔은 알앗다.

 

그 중 dao가 있고 없는 구조 차이가 눈에 띄어서 두개의 차이를 지피티쨩에게 물어봤다.

 

1. DTO + DAO + Mapper + Service 구조

**DAO(Data Access Object)**를 사용하여 데이터베이스 접근을 담당하는 구조.

 

 

구조

1. DTO (Data Transfer Object) → 데이터를 저장하는 객체
2. DAO (Data Access Object) → DB 접근 로직을 따로 관리 (쿼리 실행)
3. Mapper (MyBatis XML) → SQL 쿼리 정의
4. Service / ServiceImpl → 비즈니스 로직 처리

장점

1.  DAO가 DB 접근을 전담 → Service는 비즈니스 로직에만 집중할 수 있음
2. 테스트가 용이 → DAO를 Mocking하면 DB 없이 테스트 가능
3. 유지보수 편리 → DAO에서만 SQL을 수정하면 되므로 Service 영향이 적음
4. 추후 JPA 같은 ORM으로 변경 시 유연함 → DAO를 JPA로 변경할 수도 있음

 

단점

1. DAO 추가로 계층이 하나 더 생김 → 구조가 다소 복잡해짐
2. MyBatis의 Mapper 인터페이스와 역할이 겹칠 수 있음

 

 

2. DTO + Mapper + Service 구조 

DAO 없이 MyBatis의 Mapper 인터페이스를 바로 활용하는 구조

구조

1. DTO (Data Transfer Object) → 데이터를 저장하는 객체
2. Mapper (MyBatis XML / 인터페이스) → SQL 쿼리 정의 (DAO 역할을 함)
3. Service / ServiceImpl → 비즈니스 로직 처리

장점

1. 구조가 간결 → DAO를 생략하여 코드가 짧아짐
2. MyBatis 사용 시 직관적 → Mapper 자체가 SQL 실행 역할을 함
3.  Mapper 인터페이스로 인터페이스 기반 개발 가능

 

단점

1. Service가 DB 로직을 직접 호출하게 됨 → Service가 DB 접근과 비즈니스 로직을 같이 담당
2. ORM 변경 시 어려움 → MyBatis에서 JPA로 변경할 때 수정할 부분이 많아짐
3. 테스트가 어렵다 → DAO처럼 추상화된 계층이 없어서 Mocking이 어렵다.

 

MyBatis를 유지하면서 간단한 구조를 원한다면?
➡ DTO + Mapper + Service 유지해도 괜찮음

추후 확장성(ORM 변경 가능성) & 테스트 용이성을 고려한다면?
➡ DTO + DAO + Mapper + Service로 변경하는 것도 좋음

 

현재 MyBatis 기반이고, 구조를 최대한 간결하게 유지하고 싶다면 굳이 DAO를 추가할 필요는 없음!
하지만, JPA 같은 ORM을 고려한다면 DAO를 추가하는 게 나중에 유리할 수도 있음!