AOP의 특징과 개념

mangez_js·2024년 11월 28일

Study

목록 보기
16/47

AOP

AOP(Aspect-Oriented Programming, 관점 지향 프로그래밍)는 소프트웨어 모듈 간의 공통적인 기능을 분리하여 코드의 유지보수성과 재사용성을 높이는 프로그래밍 기법

주요 개념 및 용어

  • Aspect
    ∘ 공통적으로 적용되는 관심사를 모듈화한 단위
    ∘ ex) 로깅, 트랜잭션 관리, 보안
  • Target
    ∘ Aspect를 적용 하는 곳 (클래스, 메서드) -> 어떤 대상에 부가기능을 부여할 것인가
  • Advice
    ∘ 실질적으로 어떤 일을 해야할 지에 대한 것, 실질적인 부가기능을 담은 구현체
    • @Before : 메서드 실행 전에 실행
    • @After : 메소드 실행 후 실행
    • @Around : 메소드 실행 전, 후에 실행
    • @AfterReturning : 메소드가 성공적으로 실행된 후 실행
    • @AfterThrowing : 예외가 발생한 후 실행
  • JoinPoint
    ∘ 프로그램 실행 중에 Aspect가 적용될 수 있는 지점입니다.
    ∘ ex) 메서드 호출, 객체 생성, 예외 발생
  • PointCut
    ∘ 실제 Advice가 적용될 지점, Spring AOP에서는 Advice가 적용될 메소드를 선정
    ∘ ex) 특정 패키지나 클래스의 메서드에만 적용
  • Weaving
    ∘ Aspect를 코드에 적용하는 과정
    ∘ 시점에 따라 컴파일 타임, 로드 타임, 런타임으로 구분

적용 방식

  • 컴파일 시점
    ∘ .java 파일을 컴파일러를 통해 .class를 만드는 시점에 부가 기능 로직을 추가하는 방식
    ∘ 모든 지점 적용 가능
    ∘ AspectJ가 제공하는 특별한 컴파일러를 사용해야 하므로, 그것이 필요한 점과 복잡하다는 단점
  • 클래스 로딩 시점
    ∘ .class 파일을 JVM 내부의 클래스 로더에 보관하기 전에 조작하여 부가 기능 로직 추가하는 방식
    ∘ 모든 지점에 적용 가능
    ∘ 특별한 옵션과 클래스 로더 조작기를 지정해야하므로 운영하기 어려움
  • 런타임 시점
    ∘ 스프링이 사용하는 방식
    ∘ 컴파일이 끝나고 클래스 로더에 이미 다 올라가 자바가 실행된 다음에 동작하는 런타임 방식
    ∘ 실제 대상 코드는 그대로 유지되고, 프록시를 통해 부가기능이 적용된다.
    ∘ 프록시는 메소드 오버라이딩 개념으로 동작하기 때문에 메소드에만 적용 가능 -> 스프링 빈에만 AOP를 적용 가능
    ∘ 스프링만 있으면 AOP를 적용할 수 있기에 스프링 AOP는 런타임 방식을 사용

특징

  • 프록시 패턴 기반
    ∘ Spring은 타겟 객체에 대한 프록시를 만들어서 제공한다.
    ∘ 타겟을 감싸는 프록시는 런타임에 생성된다.
    ∘ 프록시는 Advice를 타겟 객체에 적용하면서 생성되는 객체
    ∘ 프록시의 사용 이유는 접근 제어 및 부가기능을 추가하기 위함이다.
  • 프록시 호출을 가로챔(Intercept)
    ∘ 프록시는 타겟 객체에 대한 호출을 가로챈 다음 Advice의 부가기능 로직을 수행하고 난 후에 타겟의 핵심 기능 로직을 호출 한다.
    • 전처리 어드바이스
      ∘ 타겟의 핵심기능 로직 메소드를 호출한 후에 부가가능을 수행하는 경우도 있다.
    • 후처리 어드바이스
  • 메소드 JoinPoint만 지원한다.
    ∘ Spring은 동적 프록시를 기반으로 AOP를 구현하므로 메소드 조인 포인트만 지원
    ∘ 핵심기능(타겟)의 메소드가 호출되는 런타임 시점에만 부가기능(어드바이스)를 적용할 수 있음
    ∘ 반면에 AspectJ 같은 고급 AOP 프레임워크를 사용하면 객체의 생성, 필드 값의 조회와 조작, static 메소드 호출 및 동기화 등의 다양한 작업에 부가기능을 적용할 수 있다.

장점

  • 중복 코드 제거
  • 효율적인 유지보수
  • 높은 생산성, 재활용성 극대화
  • 변화 수용 용이

AOP / Interceptor / Filter

필터(Filter)

  • 요청과 응답을 거른 뒤 정제하는 역할
  • 스프링 컨텍스트 외부에 존재하여 스프링과 무관한 자원에 대해 동작
  • 서블릿 필터는 DispatcherServlet 이전에 실행이 되는데, 필터가 동작하도록 지정된 자원의 앞단에서 요청 내용을 변경하거나, 여러가지 체크를 수행할 수 있다
    ∘ WAS 내의 ApplicationContext에서 등록된 필터가 실행
  • 자원의 처리가 끝난 후 응답 내용에 대해서도 변경하는 처리를 할 수가 있다.
  • 보통 web.xml에 등록하고, 일반저긍로 인코딩 변환 처리, XSS 방어 등의 요청에 대한 처리로 사용한다.
  • 실행 메소드
    ∘ init() : 필터 인스턴스 초기화
    ∘ doFilter() : 전/후 처리
    ∘ destory() : 필터 인스턴스 종료

인터셉터(Interceptor)

  • 요청에 대한 작업 전/후로 가로챈다고 보면 된다.
  • 인터셉터는 스프링의 DispatcherServlet이 컨트롤러를 호출하기 전/후로 끼어든다.
    ∘ 때문에 스프링 컨텍스트 내부에서 컨트롤러(핸들러)에 관한 요청과 응답에 대해 처리한다.
  • 스프링의 모든 빈 객체에 접근할 수 있다.
  • 인터셉터는 여러 개를 사용할 수 있고 로그인 체크, 권한체크, 프로그램 실행시간 계산작업 로그확인 등의 업무처리
  • 실행 메서드
    ∘ preHandler() : 컨트롤러 메서드가 실행되기 전
    ∘ postHandler() : 컨트롤러 메서드 실행직 후 view 페이지 렌더링 되기 전
    ∘ afterCompletion() : view 페이지가 렌더링 되고 난 후
    Filter Interceptor AOP
    특징 Servlet 단위에서 실행 Servlet 단위에서 실행 Method를 감싸는 Proxy 패턴
    역할 요청과 응답을 거른 뒤 정제 요청에 대한 작업 전/후로 가로챈다. OOP로 했을 때, 중복을 줄일 수 없는 부분을 줄이기 위해 종단면에서 바라보고 처리
    사용 용도 1. 인코딩 변환 처리
    2. XSS 방어
    스프링의 모든 Bean 객체에 접근 가능
    1. 로그인/권한 체크
    2. 프로그램 실행시간 계산
    3. 로그 확인
    비즈니스단의 메서드에서 더 세밀하게 조정하고 싶을 때 사용
    1. 로깅
    2. 트랜잭션
    3. 에러 처리
    실행 메서드 및 방법 Init()
    doFilter()
    destroy()
    preHandler()
    postHandler()
    afterCompletion():view페이지 렌더링 이후
    AOP의 포인트컷
    1. @Before
    2. @After
    3. @After-returning
    4. @After-throwing
    5. @Around

AOP VS 인터셉터

스프링 인터셉터

  • DispatcherServlet이 컨트롤러를 호출하기 전/후로 끼어들어서 스프링 컨텍스트 내부에서 컨트롤러에 관한 요청, 응답을 처리한다.

  • 파라미터로 HttpServletRequest, HttpServletResponse를 사용해서 컨트롤러로 넘어가는 요청과 응답 데이터를 처리하기 좀 더 용이하다.
    스프링 AOP

  • 주로 트랜잭션, 로깅 등 비즈니스단의 메소드에서 더 세밀하게 조정하고 싶을 때 사용

  • 인터셉터와 필터는 주소(URL)로 대상을 구분해서 걸러내야 한다면 AOP는 주소, 파라미터, 어노테이션 등 다양한 방법으로 대상을 지정할 수가 있다.

  • URL 기반이 아닌 PointCut 단위로 동작하기에 인터셉터와 필터와 달리 메서드 전/후의 지점에서 자유롭게 설정이 가능하다.

    필터 VS 인터셉터

  • 필터는 WAS 단에 설정되어 스프링과 무관한 자원에 대해 동작, doFilter() 메소드만 있지만

  • 인터셉터는 스프링 컨텍스트 내부에 설정되어 컨트롤러 접근 전/후에 가로채서 기능을 동작, pre, post로 명확하게 분리된다.

  • 필터와 인터셉터는 각각 관리되는 컨테이너와 Request/Response의 조작 가능 여부가 다르고, 그에 따라 용도가 다르다
    ∘ 필터는 Request와 Response를 조작할 수 있지만 인터셉터는 조작할 수 없다.

  • 필터에서는 기본적으로 스프링과 무관하게 전역적으로 처리해야 하는 작업들을 처리할 수 있다.
    ∘ 대표적인 예시로 보안과 관련된 공통 작업이 있다.

  • 인터셉터에서는 클라이언트의 요청과 관련되어 전역적으로 처리해야 하는 작업들을 처리할 수 있다.
    ∘ 대표적으로 세부적으로 적용해야 하는 인증이나 인가와 같이 클라이언트 요청과 관련된 작업 등이 있다.

결론

Filter

  • 전체적인 Request단에서 어떤 처리가 필요할 때
  • 인증, 이미지 변환, 데이터 압축, 암호화 필터, 토큰 나이징 필터, XML 콘텐츠를 변형하는 XSLT 필터, URL 및 기타 정보를 캐시 하는 필터
  • 문자 인코딩 등
    Interceptor
  • 세션 및 쿠키 체크하는 http 프로토콜 단위로 처리해야 하는 업무가 있을 때
  • 로그인 세션 체크 등
    AOP
  • 비즈니스 단에서 세밀하게 조정하고 싶을 때
  • 로깅, 트랜잭션, 에러 처리 등

0개의 댓글