기존 비즈니스 로직 처리 코드를 작성할 때 우리는 일반적으로 로깅, 트랜잭션 제어, 권한 제어 등 여러 가지 작업을 습관적으로 수행한 다음 핵심 비즈니스 로직 처리 코드를 작성합니다. 코드 작성을 마치고 되돌아보니 양양샤샤에 있는 수백 줄의 코드 중 그림 6-4와 같이 실제로 핵심 비즈니스 로직 처리에 사용된 줄은 몇 줄밖에 되지 않았다. 방법마다, 수업마다, 무기력함과 후회로 오랜 세월이 흘렀습니다. 괜찮습니다. 하지만 프로젝트가 끝날 때 갑자기 권한 제어에 큰 변경이 필요하다고 결정되면 수천 개의 메서드를 하나씩 "방문"해야 하며 고통은 "더 심해질" 것입니다.
그림 6-4의 여러 메소드에 있는 공통 코드를 모두 추출하여 중앙 집중식 관리를 위해 어딘가에 배치한 다음 컨테이너가 특정 런타임 동안 이러한 공통 코드를 서로 동적으로 엮을 수 있다면 적어도 두 가지 문제를 해결할 수 있습니다. :
특정 비즈니스 로직 처리 방법을 작성할 때 Java EE 프로그래머는 핵심 비즈니스 로직 처리에만 신경 쓰면 작업 효율성이 향상될 뿐만 아니라 코드 변경이 간단하고 우아해집니다.
향후 유지관리에서는 비즈니스 로직 코드와 공통코드를 별도로 저장하고, 공통코드를 중앙에 저장하기 때문에 유지관리 작업이 간편하고 쉬워집니다.
Aspect 지향 프로그래밍 AOP 기술은 이 문제를 해결하기 위해 탄생했습니다. Aspect는 그림 6-5와 같이 로그 측면, 권한 측면, 트랜잭션 대기 측면 등 유비쿼터스 공통 기능을 나타냅니다. .
AOP 기술의 구현 원리를 심층적으로 분석하기 위해 사용자 관리 비즈니스 로직 구성 요소인 UserService(그림 6-6 참조)의 AOP 구현 프로세스를 예로 들어 보겠습니다. AOP 기술은 Java 언어의 반사 메커니즘과 동적 프록시 메커니즘을 기반으로 합니다. 비즈니스 로직 구성요소가 실행 중일 때 AOP 컨테이너는 사용자가 호출할 프록시 객체를 동적으로 생성합니다. 이 프록시 객체는 Java EE 프로그래머의 의도에 따라 대상 메서드의 연결 지점에 대한 측면을 성공적으로 잘라냈습니다. 애스펙트의 기능이 대상 메소드의 연결점과 일치하는지 여부. 비즈니스 로직의 기능이 동시에 실행됩니다. 원칙적으로 호출자가 직접 호출하는 것은 실제로 AOP 컨테이너에 의해 동적으로 생성된 프록시 개체이며, 프록시 개체는 대상 개체를 호출하여 원래 비즈니스 논리 처리를 완료하고 프록시 개체는 측면과 비즈니스 논리 메서드를 합성했습니다.
이제 그림 6-6과 관련된 몇 가지 개념을 다음과 같이 설명합니다.
Aspect: 사실상 공통 기능의 구현이다. 로그 측면, 권한 측면, 트랜잭션 측면 등 실제 애플리케이션에서는 일반적으로 공통 기능의 구현을 저장하는 일반적인 Java 클래스입니다. AOP 컨테이너에서 Aspect로 인식할 수 있는 이유는 구성에 지정되어 있습니다.
조언: 측면의 구체적인 구현입니다. 대상 메소드를 참조점으로 사용하면 배치 위치에 따라 사전 알림(Before), 사후 알림(AfterReturning), 예외 알림(AfterThrowing), 최종 알림(After) 및 주변의 5가지 유형으로 나눌 수 있습니다. 알림(주변). 실제 애플리케이션에서는 일반적으로 측면 클래스의 메서드입니다. 특정 알림 유형도 구성에 지정됩니다.
조인포인트(Joinpoint): 프로그램 실행 과정에서 측면을 삽입할 수 있는 곳입니다. 예를 들어 메서드 호출, 예외 발생, 필드 수정 등이 있지만 Spring은 메서드 수준 연결 지점만 지원합니다.
Pointcut: 알림이 잘라야 하는 연결 지점을 정의하는 데 사용됩니다. 일반적으로 서로 다른 알림은 서로 다른 연결 지점을 잘라야 합니다. 이 정확한 일치는 진입점의 정규식에 의해 정의됩니다.
대상: 애스펙트에 진입하려는 객체, 즉 알림을 받는 객체입니다. 이러한 개체에는 깨끗한 핵심 비즈니스 논리 코드만 남고 모든 공통 기능 코드는 AOP 컨테이너가 절단되기를 기다리고 있습니다.
프록시 객체(Proxy): 대상 객체에 알림을 적용한 후 동적으로 생성되는 객체입니다. 프록시 객체의 기능은 대상 객체의 핵심 비즈니스 로직 기능에 공통 기능을 더한 것과 같다고 간단히 이해할 수 있습니다. 프록시 개체는 사용자에게 투명하며 프로그램 실행 프로세스의 산물입니다.
위빙(Weaving): 대상 객체에 측면을 적용하여 새로운 프록시 객체를 생성하는 프로세스입니다. 이 프로세스는 컴파일 기간, 클래스 로딩 기간 및 런타임 중에 발생할 수 있습니다. 물론 발생 지점에 따라 전제 조건도 다릅니다. 예를 들어, 컴파일 중에 발생하는 경우에는 이 AOP 구현을 지원하는 특수 컴파일러가 필요하고, 클래스 로딩 중에 발생하는 경우에는 런타임 중에 발생하는 경우에만 AOP 구현을 지원하는 특수 클래스 로더가 필요합니다. 동적 구현을 달성하기 위한 Java 언어 반영 메커니즘과 동적 프록시 메커니즘입니다.
다음은 보충설명입니다.
AOP는 Aspect Oriented 프로그래밍의 약어로, Aspect Oriented 프로그래밍을 의미하며, 사전 컴파일 및 런타임 동적 에이전트를 통해 프로그램 기능의 통일된 유지 관리를 달성하는 기술입니다.
AOP와 OOP는 서로 다른 분야에 대한 두 가지 디자인 아이디어입니다.
OOP(객체 지향 프로그래밍)는 비즈니스 처리 프로세스의 엔터티와 해당 속성 및 동작을 추상적으로 캡슐화하여 논리 단위를 보다 명확하고 효율적으로 분할합니다.
AOP는 비즈니스 처리 프로세스의 측면을 추출하여 논리적 프로세스의 다양한 부분 간의 낮은 결합 효과를 얻기 위해 처리 프로세스의 특정 단계를 처리합니다.
AOP와 OOP는 위의 문자 그대로의 의미만으로 간단히 이해할 수 있으며, 다음과 같이 이해한다고 해도 과언이 아닙니다.
OOP는 실제로 객체의 속성과 동작을 캡슐화한 것이며 AOP는 이에 대해 말할 수 없습니다. 그러나 AOP는 특정 단계와 단계를 다루고 그로부터 측면을 추출합니다. 반복되는 작동 동작이 있는 경우 AOP는 이를 추출하고 동적 에이전트를 사용하여 프로그램 기능의 통합된 유지 관리를 달성할 수 있습니다. 이는 권한 판단, 로깅 등에 관한 경우 이해될 수 있습니다. 단순히 OOP를 사용한다면 허가 판단은 어떻게 될까요? 각 작업 전에 권한 판단을 추가하시겠습니까? 로깅은 어떻습니까? 각 방법의 시작, 끝, 예외에 로그를 수동으로 추가하시겠습니까? 따라서 AOP를 사용하여 프록시의 도움으로 이러한 반복 작업을 완료하면 논리 프로세스에서 다양한 부분 간의 결합을 줄일 수 있습니다. 두 사람은 서로의 장점을 보완하고 서로를 보완합니다.
일부 AOP 개념에 대해 자세히 알아 보겠습니다.
•측면: 관심 사항의 모듈화는 여러 객체를 교차할 수도 있습니다. 트랜잭션 관리는 J2EE 애플리케이션의 교차 문제에 대한 좋은 예입니다. Aspect는 Spring의 Advisor 또는 인터셉터를 사용하여 구현됩니다.
•Joinpoint: 메서드 호출이나 특정 예외 발생 등 프로그램 실행의 명확한 지점입니다.
•Notification(Advice): 특정 연결 지점에서 AOP 프레임워크가 수행하는 작업입니다. 다양한 유형의 알림에는 "주변", "이전" 및 "던지기" 알림이 포함됩니다. 알림 유형은 아래에 설명되어 있습니다. Spring을 포함한 많은 AOP 프레임워크는 인터셉터를 알림 모델로 사용하고 연결 지점 "주변"에 인터셉터 체인을 유지합니다.
•Pointcut: 알림이 트리거될 연결 지점 모음을 지정합니다. AOP 프레임워크에서는 개발자가 정규 표현식 등을 사용하여 진입점을 지정할 수 있도록 해야 합니다.
•소개: 통지된 클래스에 메소드 또는 필드를 추가합니다. Spring은 조언된 객체에 새로운 인터페이스를 도입하는 것을 허용합니다. 예를 들어 가져오기를 사용하면 모든 객체가 IsModified 인터페이스를 구현하여 캐싱을 단순화할 수 있습니다.
•대상 개체: 연결 지점을 포함하는 개체로, 알림 개체 또는 프록시 개체라고도 합니다.
•AOP 프록시: 알림을 포함하여 AOP 프레임워크에서 생성된 개체입니다. Spring에서 AOP 프록시는 JDK 동적 프록시 또는 CGLIB 프록시일 수 있습니다.
•위빙(Weaving): 조언된 객체를 생성하기 위해 측면을 조립합니다. 이는 컴파일 타임(예: AspectJ 컴파일러 사용) 또는 런타임에 수행될 수 있습니다. Spring은 다른 순수 Java AOP 프레임워크와 마찬가지로 런타임에 위빙을 완료합니다.
Spring의 AOP 프록시는 Spring의 IoC 컨테이너에 의해 생성 및 관리되며 해당 종속성도 IoC 컨테이너에 의해 관리됩니다. 프로젝트에서 Spring의 AOP가 어떻게 구현되는지에 대해서는 다음 블로그에서 로깅을 예로 들어 학습하겠습니다.