JPA Repository? DAO, VO?

그동안 나는 JPA만 깔짝였었는데(?) 회사 오니 MyBatis를 하게 되어서(?) 유감이다.

STS 쓴다는 말만 들었을 때는 나는 JPA만 공부해 봤으니 나름 당연하다는 듯이 'QueryDSL도 빨리 공부해야겠다!'라고 생각했는데 경기도 오산이었다 ㅎ.ㅎ

 

암튼, 이 내용을 정리하게 된 계기는 DAO, VO와 Repository 패턴의 차이가 궁금해서다.

 

쿼리도 하나하나 직접 짜서 매핑해줘야 하니, 끝날 생각 없는 긴긴 쿼리문들을 보며 이걸 내가 어떻게 이해하지 생각했었는데..

아직도 열심히 보고 또 보고 실행시켜 보는 단계지만 그래도 내가 배웠던 거랑 비교해서 알아가면 이해가 더 쉽지 않을까 하는 기대감에 둘이 비교해보려고 한다.

 

물론 부족하고 틀린 부분도 있겠지만 그건 미래의 내가 업서트 해나갈 거다 ㅎㅎ!

 

 

 

 

[1] JPA를 사용하는 경우(Repository)

뜬금없이 Repository를 언급하냐고 할 수 있겠으나, 찾아보니 이걸 알아야겠더라.

 

JPA(Java Persistence API)

• 자바 객체와 관계형 데이터베이스 간의 매핑을 자동화하는 표준 ORM(Object-Relational Mapping) 기술
• 즉, 자바 Class 랑 RDB 테이블을 매핑해 주어 쿼리문이 아닌 메서드로 DB를 만질 수 있게 된다. 그렇게 되면, 개발자는 비즈니스 로직에 더 집중할 수 있게 됨!
• 반복되는 쿼리문을 처리해 주니 간편하고, 무엇보다 객체중심으로 개발할 수 있어 유지보수에 용이하다.

이러한 JPA를 기반으로 CRUD 및 기타 데이터 접근 작업을 추상화하여 제공해 주는 인터페이스가 바로 리포지토리다.

JPA가 제공하는 Repository를 통해 DAO 패턴을 자동으로 구현할 수 있다.

 

그러니, JPA를 쓰면 Repository가 DAO 역할을 대신해 주므로 별도의 DAO 클래스가 필요 없게 된다.

 

 

 

반대로 JPA를 쓰지 않는 경우 구현 패턴에 대해 간단히 알아보자.

 

 

[2] JPA를 사용하지 않는 경우 (JDBC Template, MyBatis)

JPA는 객체 중심 개발로 클래스랑 테이블을 자동 매핑해 준다.

그러니, JPA를 쓰지 않는다면 SQL을 직접 작성해야 한다.

사용할 데이터 접근 기술에 맞게 개발자가 데이터 접근 로직을 직접 구현해야 한다. 

 

JPA를 사용하지 않는 경우에는 데이터 접근이 필요하여 직접 DAO 패턴을 구현해야 한다(자연스럽게 Repository 인터페이스는 사용되지 않는다).

DAO는 데이터베이스와의 모든 CRUD 작업을 수행하는 전담 계층이 되는 것이다.

 

 

➕DAO, VO?

DAO랑 VO가 뭐 하는 애인지도 정리해 보겠다.

 

DAO(Data Access Object)

• 데이터에 접근하기 위한 객체
• DB 접근 로직을 분리하고자 사용
• DB에 직접 접근하여 CRUD 등 기능을 수행

VO(Value Object)

• 값 타입을 표현하기 위한 객체
• Read-Only
• @Getter 기능만 존재함
• 값 자체의 의미를 가진 불변 클래스

 

DAO의 역할

DAO는 단일 책임 원칙(SRP), 관심사의 분리(SoC), 캡슐화 원칙에 따라 DB와의 모든 CRUD 작업을 캡슐화하는 전담 객체로 설계되어야 한다.DAO는 단순히 "필요한 데이터를 가져오기"위한 객체가 아닌 것이다.데이터 접근과 관련된 모든 작업을 담당하는 계층이다.

 

 

 

[결론] DAO/VO와 JPA, Repository 관계

JPA를 사용할 경우, Spring Data JPA의 Repository 인터페이스가 DAO 패턴을 구현하는 역할을 수행한다.JPA를 사용하지 않는다면 개발자가 직접 DAO를 구현해야 하고 이때 Repository 계층은 사용되지 않는다(그럴 필요가 없다).