언어의 변천사
POP: 절차지향
- 어떤 순서에 의해 개발을 할 것인지
- 전체 모든 언어중 가장 나온 방법론
- 규모가 작으면 POP도 상관없으나 일정 규모 이상으로 올라가면 코드의 중복이 심각해짐
OOP, FOP
- OOP, FOP에서도 중복코드가 있기는 있음
AOP (Aspect: 관점지향)
사용이유
1. 관심사 분리
- 비즈니스 로직을 건들이지 않기 위해서 사용함
- 비즈니스 로직 구현 개발자는 부가적인 기능을 생각하지 않고 개발할 수 있음
- 비즈니스 로직외에 인증이나 트랜잭션에 대해 고민할 필요가 없음
- 비즈니스 로직을 가독성과 유지보수성을 높인채로 둘 수 있음
2. 중복 발생 방지
AOP 구현 핵심 기술은?
Proxy 생성 기술입니다...
- Proxy: Target객체에 Advice가 적용된 후 생성되는 객체
- 스프링은 대상(target)이 되는 객체에 프록시를 만들어 제공한다. 대상객체에 직접 접근하기보다는 프록시를 통해서 간접적으로 접근하게 된다. 이 과정에서 프록시는 대상객체의 메서드 실행 전.후에 실행하게 된다.
- 프록시객체 생성 방식: Interface구현 여부에 따라 다름
| AOP Interface기반 | CGLIB 라이브러리 |
|---|---|
| 대상객체가 인터페이스를 구현했다면 | 대상객체가 인터페이스를 구현하지 않았다면 |
| 자바 리플렉션(java.lang.reflect) API가 제공하는 Proxy 를 이용하여 생성 | CGLIB를 이용하여 프록시 생성 |
| 해당 프록시객체는 target과 동일한 인터페이스를 구현, 필요한 메서드 호출, 즉 인터페이스에 정의되지 않은 메서드는 호출 불가능 | CGLIB는 대상 클래스를 상속받아 프록시를 구현한다. 따라서 대상객체가 final인 경우 프록시를 생성할 수 없으며, 메서드가 final이라면 AOP 적용 불가능 |
들어가기 전
@Transactional
- 어노테이션으로 트랜잭션을 관리한다면 그 코드가 어딘가에 있을 것임
BoardServiceImpl의 구현체
- $Proxy44: AOP방법론에 의해 만들어진 Proxy 객체
개념
관심사의 분리
- Core Concern: 핵심적인 관심사 (출금,입금,이체,공과금)
- Cross-cutting Concern:부가적인 관심사 (인증,로깅,트랜잭션)
관심사에 따른 개발 분리
- 자기의 관점에 따라서만 업무를 보면 된다
- 타겟 로직에 집중하는 개발자
- Target 객체는 Advice를 받는 객체
- 핵심 비즈니스 로직이 있는 객체
- 어드바이스 (트랜잭션,인증..) 개발자
- 타겟 로직에 집중하는 개발자
- Weaving: 별개로 개발된 타겟과 별개로 개발된 어드바이스가 런타임에 서로 맞물리게 되는 것
- Joinpoint: 언제 위빙할 건지?
예시
하나은행
- 트랜잭션 관리
- System Logging이라는 모든 기능이 보안을 위해 공통모듈로 들어가야함
- 비번 인증(authentication)도 모두 필요함
출금
- 출금, 입금, 이체, 공과금 납부
- 출금시 10만원인출했는데 돈이 걸려서 9만원밖에 안나왔다면?
- 차감되고 인출이 된 것일테니 이 경우 롤백이 필요함
- 트랜잭션 관리가 되어야함
입금
- 10만원 입금하다가 9만원 넣고 한 장이 걸림
- 내 통장에 10만원이 들어갔을까? -> 안들어갔을 것
- 원자성으로 트랜잭션이 관리가 되어야함
이체
- 하나에서 농협으로 이체할 때, 농협 문제로 이체가 안되어 받는 사람이 못받았다면? 여기서도 트랜잭션관리가 되어야함
장점
- 중복 코드의 제거
- 횡단 관심(CrossCutting Concerns)을 여러 모듈에 반복적으로 기술되는 현상을 방지
- 비즈니스 로직의 가독성 향상
- 핵심기능 코드로부터 횡단 관심 코드를 분리함으로써 비즈니스 로직의 가독성 향상
- 생산성 향상
- 비즈니스 로직의 독립으로 인한 개발의 집중력을 높임
- 재사용성 향상
- 횡단 관심 코드는 여러 모듈에서 재사용될 수 있음
- 변경 용이성 증대
- 횡단 관심 코드가 하나의 모듈로 관리되기 때문에 이에 대한 변경 발생시 용이하게 수행할 수 있음
용어
Joinpoint(결합점)
- target과 advice과 완전히 별개로 개발되다가 엮어야할(weaving) 시점과 영역
- 예시
- 클래스 로딩단계
- 변수선언 단계
- 메서드 실행 joinpoint : Spring에서 유일하게 지원하는 joinpont
Pointcut(위빙 대상 골라내는 법)
- target, advice를 만들고 joinpoint에서 weaving을 했을 때, 어떤 target과 어떤 advice로 weaving할 것인지 골라내는 표현식
- 하나의 advice기준으로 어떤 target을 위빙할지 골라내는 방법
- AOP는 target과 advice를 분리된 관점에서 개발 후 joinpoint에 weaving을 시킨다. 이 weaving시에는 pointcut으로 골라냄
예시
- execution(* com.xyz.service.AccountService.*(..))
- execution(public * * (..)) public 메소드 실행
- execution(* set*(..)) 모든 setter에 위빙
- within(com.xyz.service.* ) 이패키지 안 모든 메서드에 위빙
Advice
- Advice는 Aspect의 실제 구현체로 Joinpoint에 삽입되어 동작할 수 있는 코드
Advice 종류
- Before/After: weaving시점이 호출 전 후인지에 따라 구별됨
- Around: 호출 전, 후를 전부 위빙
- Before advice: joinpoint(메서도 호출) 전에 수행되는 advice
- After returning advice: joinpoint가 성공적으로 리턴된 후에 동작하는 advice
- After throwing advice: 예외가 발생하여 joinpoint가 빠져나갈때 수행되는 advice
- After (finally) advice: join point를 빠져나가는 (정상적이거나 예외적인 반환) 방법에 상관없이 수행되는
advice - Around advice: joinpoint 전, 후에 수행되는 advice
Aspect
- Aspect는 구현하고자 하는 Cross-cutting Concern이다.
- Advice + Pointcut = 하나의 Aspect
- advice와 골라낼 수 있는 법인 pointcut을 하나로 합친 것
Advisor
- Aspect를 개발자가 정한 것이아닌 프레임워크가 제공해주는 것
- Aspect와 유사한 의미
aop-context.xml
propagation
- MANDATORY
- 필수관계, 반드시 트랜잭션을 관리해야하는데 그 트랜잭션이 다른 트랜잭션에 의존해야할 때
- NESTED
- 하나의 트랜잭션이 있고 그 트랜잭션안에 중첩되고 있을 때
- 단독으로 돌릴 수 없음
- NEVER
- 절대로 트랜잭션을 관리하지않겠다
- NOT_SUPPORTED
- 트랜잭션 관리를 지원하지 않겠다
- REQUIRED
- 관리해야한다, 그러나 새로운 트랜잭션이 여기에서 시작되는건 아니다
- NESTED는 반드시 안에서 돌아야하고
- REQUIRED는 안에서 돌수도, 밖에서 돌수도, 어쨌든 관리가 필요하다는 것
- REQUIRES_NEW
- 반드시 새로운 트랜잭션이 만들어져서 관리가 되어야함
ISOLATION
- 고립정책은 난이도가 너무 올라가기때문에 propagation의 REQUIRED정도만 다룰 것
선언적 프로그래밍
- 코드로 짜야하는걸 어노테이션으로 선언하여 끝
갈 길이 멀다