• 스프링이 어떻게 성격이 비슷한 여러 종류의 기술을 추상화하고 이를 일관된 방법으로 사용할 수 있도록 지원하는지 살펴보기

🌱 Branch chapter05/refactor5.1에 실습 적용

• 의도 : 정기적으로 사용자의 활동 내역을 참고해서 레벨을 조정해주는 기능 추가

• 코드 반영 : User 클래스 -> **사용자 레벨 필드 [level : BASIC, SILVER, GOLD]**를 추가

  DB에 varchar 타입으로 선언하고 문자형으로 BASIC, SILVER, GOLD를 넣을 수도 있지만,

  일정한 종류의 정보는 Enum을 이용하는게 안전하다

  ▶ 이넘 클래스 추가 완료

  public enum Level {
      BASIC(1), SILVER(2), GOLD(3);
  
      private final int value;
  
      Level(int value) {
          this.value = value; 	
          // DB에 저장할 int 타입의 값을 가지고 있지만 겉으로는 Level 타입 오브젝트
      }
  
      // ...
  }

  ▶ DB 필드 추가 완료 : users 테이블의 필드 추가

▶ UserService 클래스 생성

🌱 Branch chapter05/refactor5.2에 실습 적용

사용자 레벨 업그레이드를 시도하다가 중간에 예외가 발생했을 경우 그전에 업그레이드 했던 사용자도 다시 원래 상태로 돌아갔는지 확인하기

-> 뒤에 처리에 예외가 발생했음에도 불구하고 앞의 업그레이드는 돌아가지 않는다

java.lang.AssertionError: 
Expected: is <BASIC>
     but: was <SILVER>

• 더 이상 나눌 수 없는 단위 작업

• 원자성 : 작업을 쪼개서 작은 단위로 만들 수 없는 트랜잭션의 핵심 속성

• 중간에 예외가 발생해서 작업을 완료할 수 없다면 아예 작업이 시작되지 않은 것 처럼 초기 상태로 돌려놔야한다

트랜잭션 롤백 : 두 가지 작업이 하나의 트랜잭션이 될 때, 두 번째 SQL이 수행 시 문제가 발생할 경우, 앞에서 처리한 SQL 작업도 취소시켜야 한다

트랜잭션 커밋 : 여러 개의 SQL을 하나의 트랜잭션으로 처리하는 경우에 모든 SQL 수행 작업이 다 성공적으로 마무리됐다고 DB에 알려준 후 작업을 확정지음

• Rollback : 모든 작업을 무효화하는 롤백
• Commit : 모든 작업을 다 확정하는 커밋

하나의 Connection을 가져와 사용하다가 닫는 사이에서 일어남

트랜잭션의 시작과 종료는 Connection 오브젝트를 통해 이루어진다

Connection c = dataSource.getConnection();

c.setAutoCommit(false);		// 트랜잭션 시작

// ...
// ...

c.commit();
// or
c.rollback();

▶ setAutoCommit(false)로 트랜잭션의 시작을 선언하고 commit() 또는 rollback()으로 트랜잭션을 종료하는 작업을 **트랜잭션의 경계설정(transaction demarcation)**이라고 한다

▶ 로컬 트랜잭션 : 하나의 DB 커넥션 안에서 만들어지는 트랜잭션

(1) DB Connection 생성
(2) 트랜잭션 시작
try{
    (3) DAO 메소드 호출
    (4) 트랜잭션 커밋
} catch(Exception e){
    (5) 트랜잭션 롤백
}finally {
    (6) DB Connection 종료
}

• UserService 메소드들에 Connection 파라미터가 추가된다? -> DAO를 필요로 할때 그 사이 모든 메소드에 걸쳐서 Connection 오브젝트가 계속 전달돼야 한다
• Connection 파라미터가 UserDao 인터페이스 메소드에 추가되면 UserDao는 더이상 데이터 액세스 기술에 독립적일 수가 없다는 점

• UserService에서 트랜잭션을 시작하기 위해 만든 Connection 오브젝트를 특별한 저장소에 보관해두고, 이후에 호출되는 DAO 메소드에서는 저장된 Connection을 가져다가 사용하게 하는 것

• 트랜잭션 동기화 저장소는 작업 스레드마다 독립적으로 Connection 오브젝트를 저장하고 관리하기 때문에 다중 사용자를 처리하는 서버의 멀티스레드 환경에서도 충돌이 날 염려가 없다

• 스프링은 JdbcTemplate과 더불어 트랜잭션 동기화 기능을 지원하는 간단한 유틸리티 메소드를 제공 -> DataSourceUtils

• TransactionSynchronizationManager : 스프링이 제공하는 트랜잭션 동기화 관리 클래스. 이 클래스를 이용해 먼저 트랜잭션 동기화 작업을 초기화하도록 요청

  public void upgradeLevels() throws SQLException {
      // 트랜잭션 동기화 기능을 지원하는 스프링의 유틸리티 메소드
      TransactionSynchronizationManager.initSynchronization();        // 트랜잭션 동기화 관리자를 이용해 동기화 작업을 초기화
  
      Connection c = DataSourceUtils.getConnection(dataSource);       // DB 커넥션 생성과 동기화를 함께 해주는 유틸리티 메소드
      c.setAutoCommit(false);         // DB 커넥션을 생성하고 트랜잭션을 시작
  
      // 이후 DAO 작업은 모두 여기서부터 시작한 트랜잭션 안에서 진행된다
  
      try {
          List<User> users = userDao.getAll();
          for (User user : users) {
              if (canUpgradeLevel(user))       // 한 명씩 업그레이드 가능한지 확인
                  upgradeLevel(user);         // 한 명 업그레이드
          }
          c.commit();         // 정상 종료
      } catch (Exception e){
          c.rollback();       // 예외 발생 -> 데이터 되돌리기
          throw e;
      } finally {
          DataSourceUtils.releaseConnection(c, dataSource);   // DB 커넥션을 안전하게 닫는다
          // 동기화 작업 종료 및 정리
          TransactionSynchronizationManager.unbindResource(this.dataSource);
          TransactionSynchronizationManager.clearSynchronization();
      }
  }

• 하나의 트랜잭션 안에서 여러 개의 DB에 데이터를 넣는 작업을 해야할 필요 발생했을 때 사용
• 별도의 트랜잭션 관리자를 통해 트랜잭션을 관리
• 자바는 JDBC 외에 글로벌 트랜잭션을 지원하는 트랜잭션 매니저를 지원하기 위한 API인 JTA(Java Transaction API)를 제공

DB 클라이언트 라이브러리들이 SQL을 이용하는 방식의 공통점을 뽑아내 추상화 한 JDBC 덕분에 DB 상관없이 일관된 방법으로 데이터 엑세스 코드를 작성할 수 있는 것처럼, 트랜잭션 처리 코드에도 추상화를 도입한다면?

스프링이 제공하는 트랜잭션 추상화 기술을 이용해 애플리케이션에서 직접 각 기술의 트랜잭션 API를 이용하지 않고도, 일관된 방식으로 트랜잭션을 제어하는 트랜잭션 경계 설정 작업이 가능해진다

애플리케이션 로직의 종류에 따른 수평적 구분이든,

로직과 기술이라는 수직적인 구분이든,

이러한 적절한 분리가 가져오는 특징은 객체지향 설계의 원칙 중의 하나인 단일 책임 원칙으로 설명할 수 있다

하나의 모듈은 한 가지 책임을 가져야 한다.

하나의 모듈이 바뀌는 이유는 한 가지여야 한다.

단일 책임 원칙의 장점

어떤 변경이 필요할 때 수정 대상이 명확해짐

단일 책임 원칙을 잘 지키는 코드를 만드려면?

• 인터페이스 도입 후, DI로 연결

• 개방 폐쇄 원칙 또한 준수

• 모듈 간의 결합도가 낮아서 서로의 변경이 영향을 주지 않음

• 변경이 단일 책임에 집중되어 응집도가 높아야함

🌱 Branch chapter05/refactor5.4에 실습 적용

• 자바에서 메일을 발송할 때 표준 기술
• javax.mail 패키지에서 제공하는 자바의 이메일 클래스를 사용

• 메일 전송 메소드를 테스트하기 위해 매번 실제 메일을 발송하는 것은 부적합 -> 서버 부하
  • 테스트용 메일 서버를 이용하자
• 메일 테스트를 위해 매번 메일 수신 여부까지 일일이 확인하기 보단, 테스트 가능한 메일 서버까지만 잘 전송되는지 확인하자

• JavaMail의 API는 인터페이스를 갖는 오브젝트를 만들어 사용할 수 없다

  • Session 오브젝트를 만들어야만 메일 메시지를 생성, 전송 가능 -> Session은 클래스다..(인터페이스 X)

  • 생성자가 모두 private로 선언되어 있어서 직접 생성이 불가능하다

  • Session 클래스는 더 이상 상속이 불가능한 final 클래스이다

  • MailMessage(메일 메시지 작성), Transport(전송)도 마찬가지..

    @Deprecated
    private void sendUpgradeEMail(User user) {
        Properties props = new Properties();
        props.put("mail.smtp.host", "mail.yaans.com");
        Session s = Session.getInstance(props, null);
    
        MimeMessage message = new MimeMessage(s);   // 메일 메시지 작성
        try {
            message.setFrom(new InternetAddress(TEMP_EMAIL));
            message.addRecipient(Message.RecipientType.TO, new InternetAddress(user.getEmail()));
    
            message.setSubject("Upgrade 안내");
            message.setText(user.getName()+" 사용자님의 등급이 "+user.getLevel().name()+"로 업그레이드 되었습니다");
    
            Transport.send(message);                // 전송
        } catch (AddressException e) {
            e.printStackTrace();
        } catch (MessagingException e) {
            e.printStackTrace();
        }
    }

Spring에서는 JavaMail에 대한 추상화 기능 제공

MailSender Interface 사용 : SimpleMailMessage 인터페이스를 구현한 클래스에 담긴 메일 메시지 전송을 하는 메소드로 구성

private void sendUpgradeEMail(User user){
    // (스프링이 재공하는 )JavaMail을 사용해 메일 발송 기능을 제공하는 JavaMailSenderImpl 클래스
    JavaMailSenderImpl mailSender = new JavaMailSenderImpl();
    mailSender.setHost("mail.server.com");

    SimpleMailMessage mailMessage = new SimpleMailMessage();

    mailMessage.setTo(user.getEmail());
    mailMessage.setFrom(TEMP_EMAIL);

    mailMessage.setSubject("Upgrade 안내");
    mailMessage.setText(user.getName()+" 사용자님의 등급이 "+user.getLevel().name()+"로 업그레이드 되었습니다");

    mailSender.send(mailMessage);
}

DummyMailSender가 빈 클래스임에도 불구하고 메일 기능 테스트를 함에 있어서 굉장히 유용하다.

이처럼 테스트 환경에서 유용하게 사용하는 기법 :

• 테스트 대상이 되는 오브젝트의 기능에만 충실하게 수행하면서 빠르게, 자주 테스트를 실행할 수 있도록 사용하는 오브젝트를 통들어서 하는 말

  • ex) UserServiceTest의 관심사는 UserService에서 구현해놓은 사용자 정보를 가공하는 비즈니스 로직이지, 메일이 어떻게 전송될 것인지가 아님 -> 테스트 시, DummyMailSender로 전환해서 사용

• 테스트 스텁(test stub)

  • 대표적인 테스트 대역
  • 테스트 대상 오브젝트의 의존객체로서 존재 & 테스트 동안에 코드가 정상적으로 수행할 수 있도록 돕는 것
  • 일반적으로 메소드를 통해 전달하는 파라미터와 달리, 테스트 코드 내부에서 간접적으로 사용
  • DI 등을 통해 미리 의존 오브젝트를 테스트 스텁으로 변경해야한다 ex) DummyMailSender

• 목 오브젝트(mock object)

  • 테스트 대상의 간접적인 출력 결과를 검증하고, 테스트 대상 오브젝트와 의존 오브젝트 "사이"에서 일어나는 일을 검증할 수 있도록 **특별하게 설계된 오브젝트 **
  • 테스트 오브젝트가 정상적으로 실행되도록 도와주면서, 테스트 오브젝트와 자신의 사이에서 일어나는 커뮤니케이션 내용을 저장해뒀다가 테스트 결과를 검증하는 데 활용할 수 있게 해줌