기존에 ORM을 사용하면서 중요하게 생각했던 게 DAO와 DTO였는데
새로 RDB에서 거래를 구성하는 정보를 조회해오는 서버를 만들며
Mapper 기준에서는 어떤 식으로 사용을 해야할까 공부함
SQL Mapper에서 DAO를 만들기
SQL에서 DAO를 구성하는 방법은 크게 3가지로 나뉨
1. DAO Reposiotory 방식
2. Mapper Interface 방식
3. SQL Annotation 방식
DAO @Repository
- 기존 DAO 클래스 방식
@Repository 지정 및 EgovAbstractMapper extends 활용 기존 iBatis와 같은 방식
Mapper Interface
- Mapper interface 방식
Mapper 인터페이스 작성 및 @Mapper annotation 지정 @Mapper는 marker annotation(표준프레임워크 제공)
SQL Annotation
- SQL DML Annotation 방식
query xml 없이 mapper 인터페이스 상 @Select, @Insert 등을 활용 Dynamic SQL 등의 사용에 제약이 있음
Mapper Interface의 사용
세 가지 방식 중에서 Mapper Interface 방식을 사용 중이기에
Mapper Interface 방식을 정리
- Mapper Interface가 DAO를 대신하여 DB에 접근 후 데이터를 조회
- @Mapper Annotation을 통해 Mapper를 구성
- 패키지 경로를 포함한 클래스 풀네임
aaa.bbb.ccc.EmployerMapper을 mapper.xml 상의 namespace와 연동, 인터페이스 메소드가 query id로 호출
mapper.xml
<Mapper namespace="aaa.bbb.ccc.EmployerMapper">
<Mapper>EmployerMapper.java
@Mapper("employerMapper")
public interface EmployerMapper {
public List<EmpVO> selectEmployerList(EmpVO vo);
public EmpVO selectEmployer(BigDecimal empNo);
public void insertEmployer(EmpVO vo);
public int updateEmployer(EmpVO vo);
public int deleteEmployer(BigDecimal empNo);
}이렇게 DAO인 Mapper Interface와 mapper.xml이 연동되었다면
서비스 클래스에서 사용하기 위한 객체 의존성 주입이 필요
@Service
public class EmployerService() {
@Autowired
Private EmployerMapper empMapper;
}Entity 클래스의 분리
- Mapper Interface를 사용하는 경우 DTO와 Entity를 분리할 필요가 없다
- Mapper에게 DTO → Entity 클래스로 변환하는 작업을 위임함으로써 Controller는 더이상 두 클래스의 변환 작업을 신경쓰지 않아도 된다. 역할 분리로 인해 코드 자체가 깔끔해진다
- Mapper가 엔티티(Entity)클래스를 DTO 클래스로 변환해주기때문에 서비스 계층에 있는 Entity 클래스를 API 계층에서 직접적으로 사용하는 문제가 해결된다
결론적으로 JPA에서 테이블을 정의하고 해당 테이블과 관련이 있는 또 다른 엔티티와의 관계를 정의하는 것이 엔티티이고, SQL Mapper의 경우 직접 작성한 SQL 쿼리를 기반으로 객체를 정의하기 때문에 별도로 테이블 관계를 설정해줄 필요가 없다
ATM