SpringAOP의 이해

객체 지향 프로그래밍을 보완하는 AOP(Aspect Orient 프로그래밍)는 트랜잭션 관리, 보안 검사, 캐싱, 객체 풀 관리 등과 같은 교차 속성을 가진 일부 시스템 수준 서비스를 처리하는 데 널리 사용됩니다. . AOP 구현의 핵심은 AOP 프레임워크에 의해 자동으로 생성되는 AOP 프록시에 있습니다. AOP 프록시는 정적 프록시와 동적 프록시의 두 가지 범주로 나눌 수 있습니다. AOP 프록시 클래스는 컴파일 타임 향상이라고도 하며, 동적 프록시는 JDK 동적 프록시, CGLIB 등을 사용하여 런타임 시 메모리에 AOP 동적 프록시 클래스를 "일시적으로" 생성합니다. 런타임 향상이라고도 합니다.

AOP의 존재 가치

전통적인 OOP 프로그래밍에서는 객체가 핵심입니다. 전체 소프트웨어 시스템은 일련의 상호 의존적인 객체로 구성되며 이러한 객체는 하나씩 클래스로 추상화됩니다. 첫째, 클래스 상속을 사용하여 클래스 간의 일반 관계부터 특정 관계까지 관리할 수 있습니다. 소프트웨어의 규모가 커지고 애플리케이션이 점차 업그레이드되면서 OOP로 해결하기 어려운 문제들이 점차 나타나게 됩니다.

특정 속성과 동작을 가진 일련의 개체를 분석하고 추상화할 수 있으며, 이러한 개체 간의 협업을 통해 완전한 소프트웨어 기능을 구성할 수 있습니다. 객체는 상속될 수 있으므로 동일한 기능이나 특성을 가진 속성을 계층적 클래스 구조 시스템으로 추상화할 수 있습니다. 소프트웨어 사양의 지속적인 확장, 전문적인 업무 분업의 증가, OOP 적용 사례의 증가로 인해 OOP가 잘 해결할 수 없는 몇 가지 문제가 노출되었습니다.

이제 시스템에 완전히 유사한 코드가 3개 있다고 가정합니다. 이러한 코드는 일반적으로 "복사" 및 "붙여넣기" 방식으로 완성됩니다. 그림 1에서 볼 수 있듯이.

그림 1. 여러 위치에 동일한 코드가 포함된 소프트웨어

그림 1의 회로도를 보면 일부 독자는 이 단점을 발견했을 수 있습니다. 접근 방식: 어느 날 그림 1의 어두운 코드 부분을 수정해야 한다면 수정을 위해 세 곳에서 코드를 열어야 합니까? 이 코드가 3곳이 아닌 100곳, 심지어 1,000곳에 포함되어 있다면 어떻게 될까요?

이 문제를 해결하기 위해 우리는 보통 그림 1과 같이 어두운 코드 부분을 메소드로 정의한 후 세 개의 코드 세그먼트에서 메소드를 호출합니다. 이러한 방식으로 소프트웨어 시스템의 구조를 그림 2에 나타내었다.

그림 2 메소드 호출을 통한 시스템 기능 구현

그림 2의 소프트웨어 시스템에서 어두운 부분의 코드를 수정해야 하는 경우, 수정하기만 하면 됩니다. 전체 시스템에서 이 메서드를 호출하는 위치가 아무리 많아도 프로그램은 이러한 위치를 수정할 필요가 없으며 호출된 메서드만 수정할 수 있습니다. 이렇게 하면 나중에 유지 관리가 복잡해집니다. 소프트웨어가 크게 줄어듭니다.

그림 2에 표시된 방법 1, 방법 2, 방법 3의 경우에도 대부분의 애플리케이션 시나리오를 해결할 수 있는 다크 방법을 명시적으로 호출해야 합니다. 그러나 좀 더 특수한 경우: 애플리케이션은 다크 메소드와 완전히 분리되기 위해 메소드 1, 메소드 2, 메소드 3이 필요합니다. 메소드 1, 메소드 2, 메소드 3은 다크 메소드를 직접 호출할 필요가 없으므로 어떻게 해야 할까요? 해결해?

소프트웨어 시스템 요구 사항은 매우 자주 변경되므로 초기 시스템 설계 방법 1, 방법 2, 방법 3에서는 핵심 비즈니스 기능만 구현했습니다. 일정 시간이 지나면 방법 1, 방법 2 및 방법 3을 제공해야 합니다. 모든 거래 통제 강화를 위한 방법 3; 일정 시간이 지난 후 고객은 사용자 적법성 확인이 필요한 방법 1, 방법 2 및 방법 3을 제안했으며, 시간이 지나면 합법적인 사용자만 이러한 방법을 실행할 수 있습니다. 다시 방법 2, 방법 3에 로깅을 추가해야 하는데 잠시 후 고객이 다시 질문을 하더군요... 이런 상황이 닥치면 어떻게 해야 할까요? 일반적으로 두 가지 접근 방식이 있습니다.

수요 사양에 따라 고객의 요청을 직접 거부합니다.

요구 사항을 수용하고 고객 요구 사항을 충족합니다.

첫 번째 접근 방식은 분명히 좋지 않습니다. 고객은 신이며 우리는 고객의 요구를 충족시키기 위해 최선을 다해야 합니다. 일반적으로 두 번째 접근 방식이 채택되는데, 이를 해결하는 방법은 무엇입니까? 먼저 새 메서드를 정의한 다음 메서드 1, 메서드 2, 메서드 3을 수정하고 호출할 새 메서드를 추가합니까? 이를 수행하는 작업량은 적지 않습니다! 우리는 특별한 메소드가 있기를 바랍니다. 이 메소드를 정의하는 한 메소드 1, 메소드 2 및 메소드 3에서 명시적으로 호출할 필요가 없습니다. 시스템은 이 특수 메소드를 "자동으로" 실행합니다.

위의 아이디어는 마술처럼 들리고 약간 비현실적으로 들리지만 실제로는 이 요구 사항을 완벽하게 달성할 수 있는 기술이 AOP입니다. AOP는 특히 시스템의 다양한 모듈(다양한 방법)에 분산된 교차 문제를 처리하는 데 사용됩니다. Java EE 애플리케이션에서 AOP는 트랜잭션 관리 및 보안 검사와 같은 일부 교차 시스템 수준 서비스를 처리하는 데 사용되는 경우가 많습니다. ., 캐싱, 개체 풀 관리 등 AOP는 매우 일반적인 솔루션이 되었습니다.

Spring AOP 원리 분석

이전 소개에서 알 수 있듯이 AOP 프록시는 실제로 AOP 프레임워크에 의해 동적으로 생성된 개체이며 대상 개체로 사용할 수 있습니다. AOP 프록시에는 대상 개체의 모든 메서드가 포함되어 있지만 AOP 프록시의 메서드는 대상 개체의 메서드와 다릅니다. AOP 메서드는 특정 진입점에서 향상된 처리를 추가하고 대상 개체의 메서드를 콜백합니다.

AOP 프록시에 포함된 메소드와 대상 객체의 메소드 다이어그램은 그림 3과 같습니다.

그림 3. AOP 프록시 메소드 및 대상 객체 메소드

Spring의 AOP 프록시는 Spring의 IoC 컨테이너에 의해 생성 및 관리되며, 그 종속성도 관리됩니다. IoC 컨테이너에 의해. 따라서 AOP 프록시는 IoC 컨테이너의 종속성 주입에 의해 제공되는 관계인 컨테이너의 다른 Bean 인스턴스를 직접 대상으로 지정할 수 있습니다.

AOP 프로그래밍을 보면 프로그래머가 참여해야 하는 부분은 단 3가지입니다.

공통 비즈니스 구성 요소를 정의합니다.

하나의 진입점이 여러 비즈니스 구성요소에 걸쳐 있을 수 있습니다.

일반 비즈니스 구성 요소에 대한 AOP 프레임워크에 통합된 처리 작업인 향상된 처리를 정의합니다.

위 3개 부분 중 첫 번째 부분이 가장 일반적인 내용이므로 추가 설명이 필요하지 않습니다. 그러면 AOP 프로그래밍의 핵심은 진입점을 정의하고 향상 처리를 정의하는 것입니다. 적절한 진입점과 향상된 처리가 정의되면 AOP 프레임워크는 자동으로 AOP 프록시를 생성하며 AOP 프록시의 메서드는 대략 다음 공식을 갖습니다.

프록시 객체의 메서드 = 향상된 처리 + 프록시 객체의 메소드

위의 비즈니스 정의에서 Spring AOP의 구현 원리는 실제로 매우 간단하다는 것을 어렵지 않게 찾을 수 있습니다. AOP 프레임워크는 AOP 프록시 클래스를 동적으로 생성하는 역할을 하며, 이 프록시 클래스의 메소드는 Advice 및 콜백 대상 객체 메소드로 구성됩니다.

앞서 언급한 그림 2에 표시된 소프트웨어 호출 구조의 경우: 방법 1, 방법 2, 방법 3... 모두 "교차" 속성이 있는 메서드를 호출해야 하는 경우 전통적인 접근 방식이 적용됩니다. 프로그래머는 방법 1, 방법 2, 방법 3...을 수동으로 수정하고 코드를 통해 이 "교차 절단" 방법을 호출해야 하지만 이 방법은 코드를 매번 변경해야 하기 때문에 확장성이 좋지 않습니다.

그래서 AOP 프레임워크가 등장했습니다. AOP 프레임워크는 새로운 프록시 클래스를 "동적으로" 생성할 수 있으며 이 프록시 클래스에는 메서드 1, 메서드 2, 메서드 3...이 포함되어 있으며 이 AOP를 호출하는 기능도 추가됩니다. "cross-cutting" 방법 - 그러나 이 호출은 AOP 프레임워크에 의해 자동으로 생성된 프록시 클래스에 의해 처리되므로 확장성이 뛰어납니다. 프로그래머는 메소드 1, 메소드 2 및 메소드 3의 코드를 수동으로 수정할 필요가 없습니다. 프로그래머는 진입점만 정의하면 됩니다. AOP 프레임워크에서 생성된 AOP 프록시 클래스에는 새로운 메소드 1, 액세스 메소드 2 및 메소드 3이 포함되어 있습니다. AOP 프레임워크는 진입점을 기반으로 방법 1, 방법 2 및 방법 3의 "크로스커팅" 속성을 사용하여 메서드를 콜백할지 여부를 결정합니다.

간단히 말하면 AOP 원칙의 비밀은 그림 2의 호출을 구현하는 프록시 클래스를 동적으로 생성하는 것입니다. 이 호출에서는 프로그래머가 코드를 수정할 필요가 없습니다.

요약

AOP는 교차 속성이 있는 일부 시스템 수준 서비스를 처리하는 데 널리 사용됩니다. AOP의 출현은 개발자가 교차 속성을 사용하여 서비스를 보다 우아한 방식으로 처리할 수 있도록 하는 OOP의 좋은 보완책입니다. AspectJ이든 Spring AOP이든 어떤 종류의 AOP 구현이든 상관없이 모두 AOP 프록시 클래스를 동적으로 생성해야 합니다. 유일한 차이점은 AOP 프록시 클래스를 생성하는 타이밍입니다. AspectJ는 컴파일 타임에 AOP 프록시 클래스를 생성합니다. 따라서 성능이 더 좋지만 처리를 위해 특정 컴파일러를 사용해야 합니다. Spring AOP는 런타임을 사용하여 AOP 프록시 클래스를 생성하므로 처리를 위해 특정 컴파일러를 사용할 필요가 없습니다. Spring AOP는 실행될 때마다 AOP 프록시를 생성해야 하므로 성능이 약간 저하됩니다.

SpringAOP의 이해와 관련된 더 많은 글은 PHP 중국어 홈페이지를 주목해주세요!