서론

KB IT’s Your Life 교육과정은 오전엔 주 강사님의 강의, 오후에는 실습 강사님의 지도 하에 진행된다. 오랜 시간 개발자로 지내셨던 강사님에게 직접 Spring의 패턴 변화와 그 이유에 대해 들으니 인상 깊었다. 오늘 TIL에서는 해당 내용을 정리해보고자 한다.

Spring의 DAO 패턴과 Mapper 의 등장.

1. Spring에서 DAO 패턴의 사용

Spring 프레임워크 초기에는 데이터베이스와의 통신을 위해 DAO(Data Access Object) 패턴을 많이 사용했었다. DAO 패턴은 데이터베이스와의 상호작용을 캡슐화하여, 비즈니스 로직과 데이터 접근 로직을 분리하는 것을 목표로 한다. 이 방식은 데이터 접근 로직을 특정 클래스에 집중시켜, 비즈니스 로직과의 의존성을 최소화하고 재사용성을 높이기 위해 고안되었다.

• 특징:

  • DAO 패턴은 JDBC와 같은 저수준 API를 사용해 직접 SQL 쿼리를 작성하고 실행했다.

  • 코드에서 많은 보일러플레이트 코드(예: Connection, PreparedStatement, ResultSet 처리 등)가 필요했다.

    보일러플레이트 코드(boilerplate code)란?

    보일러플레이트 코드(boilerplate code)란 반복적이고 표준화된 코드로, 실제 비즈니스 로직과는 직접적인 관련이 없지만 코드 작성 시 필수적으로 포함되어야 하는 부분을 말한다.

  • SQL 쿼리를 Java 코드 내부에 작성하는 경우가 많았으며, 이로 인해 유지보수가 어려웠다.

• 코드 예시:

  만약 당신이 JDBC를 사용해서 BoardDAO 라는 데이터 접근 객체를 만들어본다고 생각해보자.

  1. 일단 JDBC 관련 변수를 초기화해주고 USERS 테이블 데이터를 가져오기 위해 사용할 SQL 쿼리들을 작성한다.

     

  2. 이제 CRUD를 구현하자.

     

     

     

     좋은 코드는 아니고 캡슐화할 내용도 보이만 여기서 중요한건 그것이 아니니 넘어가자.

     stmt로 이루어진 상태 관리자가 보이는가?

     만약 당신이 DAO를 사용한다면 해당 게시판 내용을 모두 조회한다거나 검색같은 기능 구현할때마다 해당 커넥션과 상태관리를 한번씩 해줘야하는 보일러 플레이트 코드들이 발생한다.

위 코드에서 알 수 있듯이, DAO 패턴은 직접 SQL 쿼리를 작성하고 실행하는 방식을 사용했다.

이로 인해 많은 보일러플레이트 코드가 필요했으며, SQL 쿼리가 Java 코드 내부에 포함되기 때문에 코드의 가독성과 유지보수성이 떨어지는 문제가 발생했다.

2. MyBatis와 Mapper의 등장

DAO 패턴의 한계를 극복하기 위해 MyBatis(구 iBatis)와 같은 프레임워크가 등장하면서 Mapper 개념이 도입되었다.

Mapper는 XML 파일 또는 어노테이션을 사용하여 SQL 쿼리를 정의하고, 이를 통해 Java 객체와 데이터베이스 레코드 간의 매핑을 처리하게 되었다.

• 특징:
  • SQL을 XML이나 어노테이션에 정의함으로써 SQL 코드와 비즈니스 로직의 분리성을 강화했다.
  • DAO에서 발생하던 보일러플레이트 코드를 줄일 수 있었다.
  • 결과 매핑, 동적 SQL, 캐싱 등 다양한 기능을 지원하여 생산성이 높아졌다.
  • MyBatis와 같은 Mapper 프레임워크는 복잡한 SQL 쿼리를 쉽게 다룰 수 있게 해 주고, 객체-관계 매핑(ORM) 프레임워크인 Hibernate와 달리 SQL 제어권을 개발자가 유지할 수 있다는 장점이 있다.
• 코드 예시: 각 mybatis 프로젝트의 실습 파일을 모두 보이고 싶으나 배보다 배꼽이 더 클태니 DAO 가 사라진 자리에 도입된 코드들만 보여주겠다.

  <!-- UserMapper.xml -->
  <mapper namespace="com.example.mapper.UserMapper">
      <select id="getUserList" resultType="User">
          SELECT * FROM member
      </select>
      
      <select id="getUserInfo" parameterType="String" resultType="User">
          SELECT * FROM member WHERE id = #{id}
      </select>
      
      <insert id="insertUser" parameterType="User">
          INSERT INTO member (column1, column2, ...)
          VALUES (#{field1}, #{field2}, ...)
      </insert>
      
      <update id="updateUser" parameterType="User">
          UPDATE member SET tel = #{tel} WHERE id = #{id}
      </update>
      
      <delete id="deleteUser" parameterType="String">
          DELETE FROM member WHERE id = #{id}
      </delete>
  </mapper>

  // User Mapper
  public interface UserMapper {
      List<User> getUserList();
      User getUserInfo(String id);
      int insertUser(User user);
      int updateUser(User user);
      int deleteUser(String id);
  }

  많은 보일러 플레이트들이 제거되고 UserMapper 인터페이스가 SQL의 실행을 담당하여 스프링과 DB 사이의 경계가 명확해짐을 알 수 있다.
  

Mapper를 사용하면 SQL과 Java 코드를 분리하여 유지보수를 쉽게 할 수 있었고, DAO에서 발생하던 보일러플레이트 코드를 줄일 수 있었다.

이로 인해 복잡한 SQL 쿼리를 보다 효율적으로 관리할 수 있었으며, 생산성이 크게 향상되었다.

결론

처음에 해당 패턴과 기술들을 어떻게 사용하는지 익히는 것도 중요하지만, 역시 그 기술이 왜 쓰이는지 아는 것이 중요하다.

그리고 그런 이유를 해당 역사와 함께한 현업자에게 직접 듣고 문제 해결 사례를 통해 깊이 있는 이해를 할 수 있어 좋았다.

혼자서 공부했으면 아마 시간이 엄청 들었을 것이다. 실무 경험이 풍부한 강사진이 KB IT’s Your Life의 큰 강점이라고 느껴진다.