MyBatis를 적용하며 달라진 프로젝트 구조 이해
이전 Spring JDBC 프로젝트에서 사용했던 JdbcTemplate 대신 MyBatis Framework를 적용하여 게시판과 회원 관리 기능을 구현하였다.
기존 프로젝트에서는 Repository에서 SQL을 직접 작성하고 JdbcTemplate을 통해 실행했지만, 이번 프로젝트에서는 Mapper 인터페이스와 XML 매핑을 이용하여 SQL과 Java 코드를 분리하였다.
MVC 구조는 이전 프로젝트와 동일하지만, 데이터 접근 계층이 Repository에서 Mapper로 변경되면서 코드가 더욱 간결해졌고 SQL 관리도 쉬워졌다.
MyBatis를 사용하는 이유와 기존 프로젝트와 달라진 점도 중심으로 정리하였다.
MyBatis를 사용하는 이유
| Spring JDBC | MyBatis |
|---|---|
| JdbcTemplate 사용 | Mapper 사용 |
| Repository에서 SQL 실행 | XML에서 SQL 관리 |
| RowMapper 직접 작성 | 자동 객체 매핑 |
| SQL과 Java 코드가 함께 존재 | SQL과 Java 코드 분리 |
기존 프로젝트에서는 Repository 안에서 SQL을 작성하고 JdbcTemplate을 호출하였다.
이번 프로젝트에서는 Mapper 인터페이스만 작성하고 실제 SQL은 XML 파일에서 관리한다.
이처럼 Java 코드와 SQL을 분리하면 유지보수가 훨씬 쉬워진다.
프로젝트 구조 변화
기존 프로젝트
Controller
↓
Service
↓
Repository
↓
JdbcTemplate
↓
Database이번 프로젝트
Controller
↓
Service
↓
Mapper
↓
MyBatis
↓
Database기존 Repository가 담당하던 데이터 접근 역할을 MyBatis의 Mapper가 대신하게 되었다.
Controller 구조는 그대로 유지된다.
MVC 구조 자체는 이전 프로젝트와 동일하다.
BoardController 역시 요청을 받은 뒤 Service를 호출하고 결과를 View에 전달하는 역할만 수행한다.
@PostMapping
public String create(@ModelAttribute BoardFormDTO dto) {
boardService.create(dto);
return "redirect:/";
}Controller는 게시글 저장 방법이나 SQL을 알지 못한다.
오직
- 요청 받기
- Service 호출
- View 반환
세 가지 역할만 담당한다.
이처럼 Controller가 데이터 처리 로직을 가지지 않는 점은 이전 프로젝트와 동일하지만, 내부적으로 Repository 대신 Mapper를 사용한다는 점이 가장 큰 차이이다.
게시글 조회 흐름
브라우저
↓
BoardController
↓
BoardService
↓
BoardMapper
↓
MyBatis
↓
Database조회 결과는 다시
Database
↓
BoardMapper
↓
BoardService
↓
BoardController
↓
JSP순서로 사용자에게 전달된다.
MVC 구조는 그대로 유지되면서도 데이터 접근 방식만 변경되었다는 점을 확인할 수 있었다.
MainController의 변화
MainController는 게시글 목록을 조회하는 기능을 담당한다.
model.addAttribute(
"boards",
boardService.findAll()
);이 코드 역시 이전 프로젝트와 거의 동일하다.
달라진 점은 findAll() 내부 구현이다.
이전에는 Repository가 JdbcTemplate을 이용하여 조회했지만,
이번에는
BoardMapper.findAll()
↓
MyBatis
↓
SQL 실행과정으로 변경되었다.
Controller 입장에서는 구현 방식이 변경되어도 동일한 메서드만 호출하면 된다.
MemberController 추가
이번 프로젝트에서는 게시판뿐 아니라 회원 관리 기능도 함께 구현하였다.
MemberController 역시 동일한 구조를 따른다.
@PostMapping
public String save(MemberFormDTO dto) {
memberService.create(dto);
return "redirect:/mem";
}게시글과 회원 기능이 모두 같은 MVC 패턴을 사용하기 때문에 새로운 기능을 추가하더라도 프로젝트 구조가 일관되게 유지된다.
DTO 사용 방식의 변화
이번 프로젝트에서도 DTO를 사용하지만,
이전 프로젝트보다 변환 책임이 더 명확하게 분리되었다.
예를 들어 BoardFormDTO에는
public Board toEntity()메서드가 존재한다.
즉,
사용자 입력
↓
BoardFormDTO
↓
toEntity()
↓
Board Entity변환이 DTO 내부에서 이루어진다.
반대로 조회에서는
BoardViewDTO.fromEntity(...)를 이용하여 Entity를 화면에 필요한 DTO로 변환한다.
Board Entity
↓
fromEntity()
↓
BoardViewDTO이처럼 입력과 출력의 변환을 DTO가 직접 담당하도록 구성된 점이 이전 프로젝트보다 더 명확해졌다.
이번 프로젝트에서 새롭게 이해한 점
| 학습 내용 | 이해한 점 |
|---|---|
| MyBatis | Repository 대신 Mapper를 사용하여 데이터 접근을 수행한다. |
| SQL 분리 | SQL을 XML에서 관리하여 Java 코드와 역할을 분리하였다. |
| Mapper | 인터페이스만 작성하면 MyBatis가 구현 객체를 생성한다. |
| DTO 변환 | toEntity(), fromEntity()를 통해 객체 변환 책임을 명확히 분리하였다. |
| MVC | 전체 구조는 유지하면서 데이터 접근 방식만 변경되었다. |
느낀 점
Spring MVC 구조는 이전 프로젝트와 크게 달라지지 않았지만, 데이터 접근 계층이 Repository에서 Mapper로 변경된 것만으로도 코드가 훨씬 단순해졌다. 특히 SQL을 Java 코드에서 직접 작성하지 않고 XML에서 관리하는 방식은 유지보수 측면에서 큰 장점이 있다는 것을 이해할 수 있었다.
또한 BoardFormDTO의 toEntity()와 BoardViewDTO의 fromEntity()를 통해 입력과 출력 데이터를 명확하게 분리하는 구조를 다시 확인하면서, 객체 간 책임을 나누는 설계가 프로젝트의 확장성과 가독성을 높여준다는 점을 체감하였다.
