서비스에서 트랜젝션관리하면
1.퍼시스턴스 프레임웤을 비지니스에서 처리하는것.
2.관리하는 코드 여러곳 - 중복발생
3.다오에서 발생한 익셉션을 비지니스로직에서도 처리해야됨
실질적으로 주입되는건 IBoardServiceImpl
디버깅 찍어보면 aop방법론으로 만들어진 프록시객체가 들어와있음.
다 방법론
POP : 절차를 중점
어플리케이션 구모가 작을땐 괜찮. 커지면 중복 해결하기위해 모듈화가 필요했음
OOP : 모듈화를 객체지향으로
FOP : 모듈화를 함수지향으로
OOP, FOP적용해도 여전히 중복이 발생했음 그래서 나온게 AOP.
(Aspect 관점지향프로그래밍)
예) atm기 어플리케이션
출금, 입금, 이체, 공과금.. -> B.L
이 과정들 모두 하나의 트렌젝션으로 관리되야됨.
1) 모든 b.l에서 트랜젝션을 관리해야됨.
2) 혹시 도둑 잡기위해 과정들 기록해야됨. 보안로깅 모든 b.l에서
3) 인증
여기서 중복을 어떻게 해결할거냐가 aop의 출발점.
관심사의 분리.
반드시 짜야되는것은 출금, 입금,,.핵심관심사(core concern) 여기서 부가적인 관심사(crosscutting -횡단 concern)로 트렌젝션,,.
핵심관심사로 나온 결과물 - 타켓
부가관심사 - 어드바이스
aop적용하면 타켓, 트렌젝션, 시스템로깅, 인증하는 4명의 개발자로 나뉨. 자기 관점에 따라서만 개발-aop
뱔개로 구현되어있는 타켓과 어드바이스가 런타임시점에서 맞물려 돌아가는걸 위빙
중복제거를 위해 oop에서 aop로 옮겨간것.
joinpoint : 타켓과 어드바이스를 언제 어디에서 위빙을 하겠다는 것 표시.
스프링은 메소드 호출 조인포인트만 지원. 타켓메서드가 실행되는 시점에 결합한다.
pointcut : 어떤 타겟과 어떤 어드바이스를 위빙을 할지 골라내는 것. 하나의 어드바이스를 놓고 봤을때 그것을 어떤 타켓들에 위빙할지 결정.
joinpoint에 위빙할때 골라내는 것을 pointcut으로 하는것.
advice : before advice - 메서드 호출전에
(조인포인트 전에) 위빙. 위빙을 하는 시점이 호출전이냐 후냐로 나뉨.
aspect : advice+pointcut
advisor : 프레임웤에서 제공해줄때도 있음. 그걸 advisor라고 함.
dicontainerlab
프록시만 잘 이용하면 b.l 안건들고 다른 일 할 수 있음.
하지만 프록시 생성 코드 어려움, implement해서 pojo 스럽지 않음.
-> aspectj 프레임웤. 이거 따와서 스프링 aop만듬. 근데 aspectj가 더 좋아서 얘로씀.(스프링은 다른 프레임웍 이식성 좋음)
aop weaving 설정 해줘서 어드바이스가 자동으로 프록시됬다..?
프록시는 인터페이스로 만듦. 구현체로 바로 만들면 aop못씀.
aop사용하는 이유
1. 관심사를 분리해서 각자 자기의 관점만을 보고 개발하게 하기위해. b.l안바꿔도 됨.
게시판 image처리 - 트렌젝션처리 해줘야됨.
propagation
MANDATORY : b에서 사용된 트렌젝션 반드시 A에서 사용되야된다.
MESTED : 중첩된. 이 안에서 트렌젝션 절대 단독으로 돌아가지 않는다.
NEVER : 트렌젝션 관리 절대 안한다.
NOT-SUPPORTED : 트렌젝션 관리 제공 안한다.
REQUIRED : 관리 필요하다. MANDATORY는 반드시 안에서. 이거는 안에서 할수도 있고 외부에서 할수도 있다..