AOP
AOP를 배워야 하는 이유
- 입력된 데이터 기록하기
- 모든 기능에 들어온 매개변수 기록하기
- 문제점
- 적용될 기능에 반복해서 코드를 작성 해야함
- 로직이 조금만 바뀌어도 모두 바꿔 주어야함
- 코드의 가독성이 떨어짐
- 데이터의 기록 -> 로깅
로깅 -> 부가 기능
부가 기능 -> 인프라 로직 - 로깅은 주요기능은 될 수 없다.(부가기능)
- 인프라 로직
- 모든 기능 영역에서 나타날 수 있음
- 중복토드를 만들어낼 수 있음
- 유지보수가 힘들어짐
- 비즈니스 로직과 같이 있어 로직을 이해하기 어려워짐
- 인프라 로직 예시
- 트랜잭션 처리
- 보안
- 로깅
스프링 AOP란?
- AOP : 부가기능(advice)을 동적으로 추가해주는 기술(코드가 실행되는 과정에서 자동으로 추가)
- 관점 지향 프로그래밍 Aspect Oriented Programming
- 핵심적인 관점과 부가적인 관점을 나누어 각각 관리 하겠다.
- 관점 지향 프로그래밍은 프로그램 구조에 대한 다른 사고방식을 제공해서 객체 지향 프로그래밍을 보완한다.
- 단일 책임 원칙 : 클래스가 하나의 기능만을 가지며, 어떤 변화에 의해 클래스를 변경 해야하는 이유는 오직 하나 뿐이어야 한다는 원칙
- 핵심적인 기능이 아닌 부가적인 기능들을 횡단 관심사 또는 흩어진 관심사라고 한다.
- AOP로 구현하는 기준
- 2번이상 사용되거나 부가적인 경우 - AOP로 구현
AOP 용어 설명
- target : advcie가 추가될 객체(핵심기능)
- advice : target에 동적으로 추가될 부가 기능(코드)
- join point : advice가 추가(join)될 대상(메서드)
- pointcut : join point들을 정의한 패턴
예) execution - proxy : target에 advice가 동적으로 추가되어 생성된 객체
- weaving : target에 advice를 추가해서 proxy를 생성하는 것
- 어디에 적용할 것인가
종류 | 애너테이션 | 설명 |
around advice | @Around | 메서드의 시작과 끝 부분에 추가되는 부가기능 |
before advice | @Before | 메서드의 시작 부분에 추가되는 부가기능 |
after advice | @After | 메서드의 끝 부분에 추가되는 부가기능 |
after returning | @AfterReturning | 예외가 발생하지 않았을 때, 실행되는 부가기능 (try 구문) |
after throwing | @AfterThrowing | 예외가 발생했을 때, 실행되는 부가기능 (catch 구문) |
알아두면 좋은 점
- AOP가 여러 개 있을 때 @Order(숫자)어노테이션을 통해 순서를 정할 수 있다.(오름차순 수행)
ex) advice 앞에 @Order(1), Order(2), ... 등으로 애너테이션을 붙여서 advice의 순서를 정할 수 있다. - 내가 원하지 않는 지점은 예외처리 할 수 있다.
- AfterThrowing을 사용하면 메서드가 중간에 에러가 나도 로직처리를 할 수 있다.
- AspectJ를 사용하면 조금 더 나은 성능과 더 많은 Pointcut을 관리 할 수 있다.(하지만 비교적 더 어려움)
'[패스트캠퍼스]KDT 핀테크 서비스 백엔드 > review' 카테고리의 다른 글
16주차 Review - Spring/SpringBoot (0) | 2022.12.30 |
---|---|
15주차 Review - Spring/SpringBoot (0) | 2022.12.23 |
13주차 Review - Spring/SpringBoot - 2022. 12. 9. 15:57 작성 (0) | 2022.12.19 |
12주차 Review - Spring/SpringBoot - 2022. 12. 1. 14:12 작성 (0) | 2022.12.19 |
11주차 Review - Spring/SpringBoot - 2022. 11. 24. 14:15 작성 (0) | 2022.12.19 |