1. AOP 시작하기
여러 모듈에서 로깅, 트랜잭션과 같이 핵심 비즈니스 로직이 아닌 부가적인 목적으로 필요한 로직이 반복적으로 나타나는 것을 횡단 관심사(cross-cutting concern) 라고 한다.
애플리케이션을 바라보는 관점을 하나하나의 기능에서 횡단 관심사 관점에서 바라보고 핵심 기능과 부가 기능의 분리를 통해 모듈성을 증가시키는 것을 관점 지향 프로그래밍(Aspect-Oriented Programming) 이라고 한다.
public void transfer() {
Connection con = dataSource.getConnection();
try {
con.setAutoCommit(false);
//비즈니스 로직
con.commit();
} catch (Exception e) {
con.rollback();
throw new IllegalStateException(e);
} finally {
release(con)
}
}
위와 같이 여러 모듈에 걸쳐 중복해서 나타나는 부가 로직을 분리하여 비즈니스 로직은 핵심 기능에만 집중하고 부가 기능을 애스펙트(Aspect)라는 별도의 모듈로 분리한다.
위와 같은 트랜잭션을 수행하는 코드는 다음과 같이 바뀔 수 있을 것이다.
@Aspect
public void TransactionAspect{
@Around("execution(* com.example.order..*(..))")
public void doTransaction(ProceedingJoinPoint joinPoint){
Connection con=dataSource.getConnection();
try{
con.setAutoCommit(false);
joinPoint.proceed();
con.commit();
}catch(Exception e){
con.rollback();
throw new IllegalStateException(e);
}finally{
release(con)
}
}
}
public void transfer() {
//비즈니스 로직
}
doTransaction()
은 트랜잭션과 관련된 처리를 수행할 책임만을 지고, transfer()
는 핵심 로직만 수행할 책임만을 지게 된다.
부가 기능과 핵심 로직을 분리함으로써 하나의 메서드는 하나의 책임만을 가질 수 있게 된다. 이처럼 AOP는 OOP와 별개의 개념이 아닌 객체 지향적으로 프로그래밍 할 수 있게 도움을 준다.
AOP 적용 방법
AOP를 적용하는 방법은 다음 세 가지로 나뉠 수 있다.
- 컴파일 시점
- 클래스 로딩 시점
- 런타임 시점
컴파일 시점
소스 코드를 컴파일 하기 전, 부가 기능 코드를 핵심 기능이 코드가 있는 소스에 삽입하는 방식으로 동작한다. 이렇게 원본 로직에 부가 기능 로직이 추가되는 것을 위빙(Weaving)이라 한다.
AspectJ가 제공하는 특별한 컴파일러를 사용해서 수행할 수 있다.
클래스 로딩 시점
클래스 로딩 시점에 바이트 코드를 조작하여 부가 기능을 삽입하는 방식이다.
런타임 시점
프록시를 이용하여 부가 기능 로직이 동작하도록 하는 방식이다. 프록시를 이용하기 때문에 특별한 컴파일러나 복잡한 옵션, 클래스 로더 조작기를 설정하지 않아도 된다.
스프링 AOP가 이 방식을 사용한다.
그러나 컴파일, 클래스 로딩 시점의 AOP는 생성자, 필드 값 접근, static 메서드 접근, 메서드 실행과 같이 다양한 지점에 기능을 적용할 수 있다. 반면, 프록시 방식의 스프링 AOP는 메서드 오버라이딩의 개념으로 동작한다. 따라서 스프링 AOP의 부가 기능 적용 가능 지점(조인 포인트)는 메서드 실행으로 제한된다.
2. Spring AOP 주요 용어
타겟(target)
- 핵심 기능을 담고 있는 모듈로써 부가 기능을 부여할 대상
- 포인트 컷에 의해 결정되는 어드바이스를 받는 객체
조인 포인트(Join Point)
- 어드바이스가 적용될 수 있는 위치
- AOP를 적용할 수 있는 모든 지점
- 스프링 AOP의 경우 메서드 실행 지점
포인트컷(Pointcut)
- 어드바이스를 적용할 타겟의 메서드를 선별하는 종규표현식
- 주로 AspectJ 표현식을 사용해서 지정
- 어디에 부가 기능을 적용할 것이냐? 라는 것을 문장으로 표현한 것이다.
- 여러 조인 포인트 중에 어디에 어드바이스를 적용할 것이냐?
애스펙트(Aspect)
- 어드바이스 + 포인트 컷을 모듈화 한 것
- Spring에서는 Aspect를 빈으로 등록해서 사용한다.
- 여러 어드바이스와 포인트 컷이 함께 존재
어드바이스(Advice)
- 타겟의 특정 조인 포인트에 제공할 부가 기능
- 스프링은 어드바이스를 적용할 시점에 대한 다양한 어노테이션을 제공한다.
위빙(Weaving)
- 포인트 컷으로 결정된 타겟의 조인 포인트에 어드바이스를 적용하는 과정
AOP 프록시
- AOP 기능을 구현하기 위해 만든 프록시 객체
- 스프링 AOP는 인터페이스 구현을 이용하는 JDK Proxy와 대상 클래스를 상속하여 구현하는 CGLIB 프록시가 있다.
3. AOP 실습
포인트컷 표현식
포인트컷은 포인트컷 지시자로 시작한다.
포인트컷 지시자
타겟 오브젝트의 여러 조인 포인트 중 어드바이스를 어떻게 적용시킬지 AOP에게 알려주는 하나의 키워드
execution
- 메소드 실행 조인 포인트를 매칭한다.
within
- 특정 타입 내의 조인 포인트를 매칭한다.
args
- 인자가 주어진 타입의 인스턴스인 조인 포인트
this
- 스프링 빈 객체(스프링 AOP 프록시)를 대상으로 하는 조인 포인트
target
- 타겟 객체(스프링 AOP 프록시가 참조하는 실제 객체)를 대상으로 하는 조인 포인트
@annotation
- 메서드가 주어진 애노테이션을 가지고 있는 조인 포인트를 매칭
이 외에도 다양한 지정자가 존재한다.
execution 문법
[접근제어자] 반환타입 [패키지&클래스패턴]메서드이름(파라미터) [예외]
public void com.example.dao.Repository.save(Item)
* runSomething()
* *(..)
- 대괄호는 생략 가능하며 필수 요소는 반환 타입, 메서드 이름, 파라미터 뿐이다.
- 부모 타입을 포인트컷으로 선언한 경우 자식 타입도 매칭된다.
- 별도로 포인트컷을 분리해 관리할 수 있다. 이 경우
@Pointcut
애노테이션을 사용하면 된다.
@Pointcut("execution(* runSomething())")
public void allRunSomething(){}
어드바이스 종류
@Around
- 메서드 호출 전후에 수행
- 조인 포인트 실행 여부 선택
- 반환 값 변환
- 예외 변환 등이 가능
@Before
- 조인 포인트 실행 이전에 실행
@AfterReturning
- 조인 포인트가 정상 완료 후 실행
@AfterThrowing
- 메서드가 예외를 던지는 경우 실행
@After
- 조인 포인트가 정상 또는 예외에 관계 없이 실행(finally)
4. 스프링의 트랜잭션
어떤 기술을 사용하여 데이터 접근을 수행하고 있는지에 따라 트랜잭션을 구현하기 위한 방법도 모두 다르다. JDBC는 가장 먼저 connection
을 획득하고 JPA는 entityTransaction
을 획득한다.
스프링은 PlatformTransactionManager
인터페이스를 통해 트랜잭션에 대한 관리를 추상화하였다.
public void testTransaction() {
TransactionStatus transaction = transactionManager.getTransaction(new DefaultTransactionDefinition());
try {
// 로직 수행
transactionManager.commit(transaction);
} catch (DataAccessException e) {
transactionManager.rollback(transaction);
}
}
또한, 스프링은 AOP 기능을 이용하여 트랜잭션이 필요한 곳에 @Transactional
애노테이션만 붙여주면 이를 인식하여 트랜잭션 프록시를 적용해준다.
@Transactional
public void testTransaction() {
// 로직 수행
}
5. 트랜잭션 전파
하나의 트랜잭션 수행 중에 다른 서비스의 @Transactional
을 호출하는 경우 기존에 수행되던 트랜잭션에 호출된 트랜잭션이 참여하게 된다. 이를 트랜잭션 전파(propagation)라 한다.
스프링은 이러한 트랜잭션을 논리 트랜잭션과 물리 트랜잭션이라는 개념으로 나눈다. 하나의 물리 트랜잭션은 여러 논리 트랜잭션으로 구성되어 있으며 논리 트랜잭션 중 하나라도 롤백 된다면 모든 논리 트랜잭션, 하나의 물리 트랜잭션은 롤백된다.
스프링의 기본 옵션은 required
이다. 앞의 설명이 required
에 해당하는 내용이다. 이 외에 required_new
, support
, not_supported
, mandatory
의 옵션이 존재한다.
required_new
- 진행중인 트랜잭션에 참여하지 않고 새로운 트랜잭션이 시작된다.
- 개별 트랜잭션이 별도의 물리 트랜잭션을 가지며 커넥션도 따로 사용한다.
support
- 진행중인 트랜잭션이 있으면 참여하고 없는 경우 트랜잭션 없이 진행한다.
not_supproted
- 트랜잭션에 참여하거나 생성하지 않는다.
mandatory
- 반드시 진행중인 트랜잭션이 존재해야 한다.
- 트랜잭션이 없으면 예외가 발생한다.
'공부방' 카테고리의 다른 글
[TIL 07/04] 스프링 MVC (0) | 2023.07.06 |
---|---|
[TIL 07/03] 웹, 서블릿 (0) | 2023.07.05 |
[TIL 06/29] NamedParameterJdbcTemplate, Transaction (0) | 2023.06.30 |
[TIL 06/28] Connection Pool, DataSource, JdbcTemplate (0) | 2023.06.30 |
[TIL 06/27] JDBC (0) | 2023.06.30 |