이 기사는 주로 스프링 프레임 워크의 스프링 프레임 워크의 뼈 아키텍처의 설계 개념을 분석합니다. 이러한 구성 요소가 이러한 구성 요소가 필요한 이유는 무엇입니까? 그들은 봄의 골격 건축물을 형성하기 위해 어떻게 결합합니까? Spring의 AOP 기능은 이러한 기본 골격 아키텍처를 사용하여 어떻게 작동합니까? 이 디자인을 완성하기 위해 봄에 어떤 종류의 디자인 모델이 사용됩니까? 이 디자인 개념의 미래 소프트웨어 디자인에 대한 영감은 무엇입니까? 이 기사는이 질문에 대해 자세히 설명합니다.
봄의 골격 건축
봄에는 12 개 이상의 구성 요소가 있지만 아래에는 몇 가지 실제 핵심 구성 요소가 있습니다.
그림 1. 스프링 프레임 워크의 전체 아키텍처 다이어그램
위 그림에서 스프링 프레임 워크에는 핵심, 컨텍스트 및 콩의 세 가지 핵심 구성 요소 만 있음을 알 수 있습니다. 그들은 전체 봄 골격 아키텍처를 만듭니다. 그것들이 없으면 AOP 및 웹과 같은 상부 계층의 특성을 갖는 것은 불가능합니다. 아래는이 세 가지 구성 요소에서 주로 봄을 분석합니다.
봄의 디자인 개념
앞서 언급 한 바와 같이, 스프링의 세 가지 핵심 구성 요소가 세 가지에서 선택되면 콩 구성 요소 인 이유는 왜 Bean (BOP, Bean Oriented Programming)이어야합니다. 콩은 봄의 진정한 주인공입니다.
Spring에서 Bean의 역할은 OOP에 대한 개념과 같습니다. 공연 단계와 마찬가지로 배우는 없습니다. 봄에 왜 그렇게 중요한가? 그의 종속성 주입 메커니즘 인 구성 파일을 관리합니다. 그리고이 주입 관계는 IOC 컨테이너에서 관리되며 IOC 컨테이너의 대상은 Bean으로 포장됩니다. Spring은 Bean에 물체를 포장하여 이러한 객체를 관리하는 목적입니다.
디자인 전략은 Java의 설계 개념과 완전히 유사하지만 Java 자체의 디자인은 Spring보다 훨씬 더 복잡하지만 모두 다른 개인과 함께 일련의 정보를 설계 할 수 있습니다. 이 환경은 특정 규칙에 따라이 환경입니다. 그것에 대해 생각하면, 우리가 큰 유사한 디자인 개념에서 사용하는 다른 프레임 워크에 대해 생각하십시오.
핵심 구성 요소와 함께 작업하는 방법
앞에서 언급했듯이 Bean은 봄의 핵심 요소입니다. 공연의 배우 인 경우 컨텍스트는이 성능의 단계 배경이며 핵심은 공연의 소품이어야합니다. 그들이 함께있을 때만 좋은 쇼를 할 수있는 가장 기본적인 상태를 가질 수 있습니다. 물론, 가장 기본적인 조건은이 공연을 돋보이게 할 수 없으며, 그가 공연하는 쇼는 Spring이 제공 할 수있는 특징적인 기능입니다.
우리는 Bean이 객체라는 것을 알고 있으며,이 데이터를 생활 환경에 제공하는 방법은 컨텍스트를 위해 해결되는 문제입니다. 그들 과이 관계를 유지합니다. 따라서 컨텍스트는 IOC 컨테이너라고도합니다. 그렇다면 핵심 구성 요소의 사용은 무엇입니까? 실제로, 코어는 각 콩 사이의 관계가 각 Bean 간의 관계를 발견, 확립 및 유지하는 데 필요한 일부 열입니다.
아래 그림으로 표시 될 수 있습니다.
그림 2. 세 가지 구성 요소 관계
핵심 구성 요소에 대한 자세한 설명
여기서는 각 구성 요소의 계층 적 관계를 상세하게 소개하고 런타임시 주문 순서를 소개합니다. 우리는 봄 사용에주의를 기울여야합니다.
콩 구성 요소
스프링에 대한 Bean 구성 요소의 중요성은 구성 요소가 어떻게 설계되었는지 확인했습니다. Bean 구성 요소는 Spring의 org.springframework.beans에 포장됩니다. 이 패키지의 모든 범주는 Bean의 정의, Bean의 생성 및 Bean 분석의 세 가지를 해결합니다. 스프링 사용자의 경우, 돌보는 유일한 것은 Bean을 만들어내는 것입니다.
Springbean의 일반적인 공장 모델은 다음과 같은 공장의 상속 수준입니다.
그림 4. Thebean Factory의 상속 관계
BeanFactory에는 ListableBeanFactory, HierarchicalBeanFactory 및 Autowire 유능한 Bean Factory의 세 가지 하위 클래스가 있습니다. 그러나 위 그림에서 최종 기본 구현 클래스가 DefaultListableBeanFactory이며 모든 인터페이스를 구현한다는 것을 알 수 있습니다. 그렇다면 왜 그렇게 많은 수준의 인터페이스를 정의합니까? 소스 코드와 이러한 인터페이스의 지침을 확인하십시오. 각 인터페이스는 주로 운영 프로세스의 전송 과정에서 객체의 데이터 액세스 제한을 구별하는 경우가 있습니다. 작동 과정. 예를 들어, ListableBeanFactory 인터페이스는 이러한 콩을 나열 할 수 있음을 나타냅니다. 계층은이 콩이 상속 관계를 가지고 있음을 의미합니다. 즉, 각 콩은 아버지 콩을 가질 수 있습니다. AutoweRecapableBeanFactory 인터페이스는 Bean의 자동 조립 규칙을 정의합니다. 이 네 가지 인터페이스는 콩 수집, 콩 및 콩 동작의 관계를 공동으로 정의합니다.
Bean의 정의에는 주로 Beandefinition 설명이 포함됩니다.
그림 5. 클래스 계층 적 관계 다이어그램 정의 된 바이브;
Bean의 정의는 다양한 하위 노드를 포함하여 Spring의 구성 파일에 정의 된 노드의 모든 정보에 대한 완전한 설명입니다. Spring이 당신이 정의한 노드를 성공적으로 분석했을 때, 그는 스프링 내에 beandefinition 객체로 변환되었습니다. 모든 작업은 향후이 개체에 대해 수행 될 것입니다.
Bean의 분석 프로세스는 매우 복잡하며 여기에는 확장 할 장소가 많기 때문에 기능이 자세하게 나뉩니다. 가능한 변화에 대처할 수있는 충분한 유연성을 보장해야합니다. Bean의 분석은 주로 스프링 구성 파일을 분석하는 것입니다. 이 분석 프로세스는 주로 아래 그림에서 클래스를 통해 완료됩니다.
그림 6.Bean의 분석 클래스
물론 여기에는 특정 태그가 나와 있지 않습니다.
컨텍스트 구성 요소
컨텍스트는 Spring의 org.springframework.context에서 포장되어 있습니다. 이 환경이 어떻게 구축되는지 살펴 보겠습니다.
ApplicationContext는 응용 프로그램 환경의 기본 정보 외에도 5 개의 인터페이스를 상속받습니다. 아래는 컨텍스트의 구조 다이어그램입니다.
그림 7. Context 관련 클래스 구조 다이어그램
ApplicationScontext는 위의 그림에서 BeanFactory를 상속 받는다는 것을 알 수 있으며, 이는 스프링 컨테이너의 주요 객체가 Bean이라는 것을 보여줍니다.
ApplicationContext의 서브 클래스에는 주로 두 가지 측면이 포함됩니다.
configurablepplicationContext 컨텍스트가 수정되었음을 나타냅니다. 즉, 컨텍스트에서 기존 구성 정보를 동적으로 추가하거나 수정할 수 있습니다.
WebApplicationContext는 이름의 이름으로, 웹을 위해 준비된 컨텍스트입니다.
그런 다음 하위 다운은 컨텍스트 유형을 구성하고 컨텍스트에 액세스하는 방법을 구성하는 것입니다. 이러한 첫 번째 레벨 레벨은 완전한 컨텍스트 수준을 구성합니다.
일반적으로 ApplicationContext는 다음을 완료해야합니다.
◆ 응용 프로그램 환경을 만드십시오
◆ Beanfactory를 사용하여 Bean 객체를 만듭니다
◆ 객체 관계 테이블을 저장하십시오
◆ 다양한 이벤트를 캡처 할 수 있습니다
스프링 IOC 컨테이너로서 컨텍스트는 기본적으로 대부분의 스프링 기능을 통합하거나 대부분의 기능의 기초입니다.
핵심 구성 요소
핵심 구성 요소는 Spring의 핵심 구성 요소로서 중요한 구성 요소 중 하나가 자원에 대한 액세스 방법을 정의하는 것입니다. 이러한 방식으로 모든 리소스를 인터페이스로 추상화하는 것은 향후 디자인에서 학습 할 가치가 있습니다. 봄 에이 부분의 역할을 살펴 보겠습니다.
아래 그림은 자원 관련 구조 다이어그램입니다.
그림 8. 관련 클래스 구조 다이어그램
위 그림에서 리소스 인터페이스가 다양한 가능한 리소스 유형을 캡슐화한다는 것을 알 수 있습니다. 즉, 파일 유형의 차이가 사용자에게 차단됩니다. 리소스 제공 업체는 다른 사람들에게이를 사용하는 방법도 INPUTSTREAMSTREAP를 상속받습니다. 이러한 방식으로 모든 리소스는 입력 스트림 클래스를 통해 얻을 수 있으므로 리소스 제공 업체도 보호됩니다. 또 다른 문제는 자원을로드하는 문제, 즉 리소스의 로더가 위의 그림에서 모든 리소스를로드 할 수 있으며 그의 기본 구현은 DefaultResourceloader라는 것입니다.
맥락과 자원이 어떻게 관계를 확립했는지 살펴 보겠습니다. 먼저 관계 다이어그램을보십시오.
그림 9. 콘텍스트 및 리소스의 관계 다이어그램
위의 그림에서 볼 수 있듯이 컨텍스트는 리소스에 대한 로딩, 분석 및 설명을 완료하기 위해 사용합니다. 핵심 구성 요소와 비슷한 방법이 많이 있습니다.
IOC 컨테이너에서 작업하는 방법
앞서 언급 한 바와 같이, 핵심 구성 요소, 콩 구성 요소 및 컨텍스트 구성 요소의 구조와 상호 의존은 여기에 사용자의 관점에서 실행되는 방법과 다음과 같은 방법을 완성했습니다.
멍청한 공장을 만드는 방법
그림 2에 설명 된 바와 같이, IOC 컨테이너는 실제로 다른 두 구성 요소와 결합 된 Bean 관계 네트워크입니다. 구축 된 입구는 AbstractPollicationContext 클래스의 새로 고침 메소드에 있습니다. 이 방법의 코드는 다음과 같습니다.
목록 1.ABSTRANTAPPLICATIONCONTEXT.REFRESH
Public void refresh ()는 Beansexception, 불법적 인 경우 (this.startupshutdownmonitor) {// Pres Prarefresh (Pres Prese) 컨텍스트. Bean Crea That Proceass는이 컨텍스트에 대한 초기 ZE 메시지 소스입니다 서브 클래스. CATCH (BeanSexception ex) {// 자원을 피하기 위해 AlReam을 만들었습니다.이 방법은 전체 IOC 컨테이너 프로세스에 대한 완전한 코드를 구축하고 내부의 각 코드 라인이 기본적으로 대부분의 스프링의 원리와 기능을 이해한다는 것을 이해하는 것입니다.
이 코드는 주로 이러한 단계를 포함합니다.
◆ 순서대로 Beanfactory를 만듭니다
◆ 이벤트는 등록에 관심이있을 수 있습니다
◆ Bean 인스턴스 개체를 만듭니다
◆ 듣고 이벤트를 유발합니다
아래는 이러한 프로세스의 코드 분석과 결합했습니다.
두 번째 및 세 번째 문장은 BeanFactory를 생성하고 구성하는 것입니다. 이것은 새로 고쳐서 구성을 새로 고쳐야합니다. 다음은 BeanFactory 업데이트를위한 메소드 코드입니다.
List 2. AbsTractreAbsablepplicationContext
보호 된 void refreshbeancection (hasbeancepory) {destroybeans (); ; Synchronized (this.beanfactorymonitor) {this.beanfactory = beanfactory;} catch (ioexception ex) { " + getDisplayName (), Ex)에 대한"I/O 오류 및 NBSP;이 방법은 AbstractPlicationContext RefreshBeanFactory의 추상적 인 방법을 깨닫습니다. 콩 변형 객체의 유형은 다양한 유형의 객체를 가지고 있습니다. BeanFactory의 원래 객체는 기본리스트리스트에 비해 매우 중요합니다.
그림 10. defaultListableBeanFactory 클래스 상속 다이어그램
BeanFactory 관련 클래스 외에도 Bean 등록부와 관련이 있음이 밝혀졌습니다. 새로 고침 된 방법에는이 방법이 Bean의 정의를로드하고 분석하는 LoadBeendefinitions (BeanFactory)가 있습니다. 컨테이너.
이 과정은 다음 순차 맵에서 설명 할 수 있습니다.
그림 11. BeanFactory의 시간 서문을 만듭니다
Bean의 분석 및 등록 절차는 다음과 같습니다.
무화과
BeanFactory를 만들면 Spring 자체가 필요한 일부 도구 클래스를 추가하십시오.
AbstractApplicationContext의 다음 3 줄 코드는 Spring의 기능 확장에 중요한 역할을합니다. 처음 두 줄은 주로 구축 된 BeanFactory의 구성을 수정할 수 있습니다. 그래서 그들은 모두 스프링의 기능을 확장하므로 스프링 사용 의이 부분을 사용하는 법을 배워야합니다.
그중에서도 InvokeBeanFactoryPostprocessors 메소드에서 주로 BeanFactoryPostProcessor 인터페이스를 구현하기 위해 서브 클래스를 얻는 것입니다. 후 프로세스 비안 요법을 실행하면이 방법의 진술은 다음과 같습니다.
목록 3.BeanFactoryPostProcessor.PostProcessBeanFactory
void postprocessbeanfactory (configurableBleistablebeanfactory beanfactory)는 beansexception을 던졌습니다.
이 매개 변수는 BeanFactory에 의해 수정 될 수 있음을 나타냅니다. 사용자는 사용자가 마음대로 수정합니다.
RegisterBeanPostProcessors 메소드는 BeanPostProcessor 인터페이스의 사용자 정의의 서브 클래스를 얻고 BeanFactory 객체의 BeanPostProcessors 변수로 실행할 수 있습니다. 두 가지 방법은 BeanPostProcessor에 선언되어 있습니다. 후 프로세스 전신 - 전신 자리 화 및 후 처리 사후 테리 닐화는 Bean 객체의 초기화 중에 실행하는 데 사용됩니다. 사용자 정의 작업을 수행 할 수 있습니다.
후자의 라인 코드는 모니터링 이벤트의 초기화 등록 및 시스템의 다른 리스너는 ApplicationListener의 서브 클래스 여야합니다.
Bean 인스턴스를 생성하고 Bean의 관계 네트워크를 구축하는 방법
다음은 Instantantiated Code of Bean으로, FinishbeanCactoryInitity 방법으로 시작합니다.
Listing 4.ABSTRANTAPPLICATIONCONTEXT.FINISHBEANFactoryInitialization
void finishbeance-beanf. Lazy-Init) 싱글 톤.
콩의 인스턴스는 콩 변형에서 찾을 수 있음을 알 수 있습니다. 사전 입장선 방법의 코드는 다음과 같습니다.
List 5. DefaultListableBeanFactory.preinstantialsingletons
public void preinstantiatesingletons ()는 beansexception {if (this.logger.isinfoenabled ()) {this.logger.info ( "사전에 인스턴스테이닝 싱글 톤";} 동기화 된 (this.beendefinitionmap) {(string beanname : this. BeanDefinitionNames) {rootbeandefinition bd = getmergedlocalbeandefinition (beanname); iseageRinit; if (system.getSecurityManager ()! = null &&; smartFactoryBean의 Factoryof SmartFactoryBean) {isea gerinit = accesscontroller.doprivileged (& nb sp; new privilegedaction <boolean> () {& nb sp;) {return ((smartfactorybean) accact) iiseageinit (); ;}}}}}}}}}여기에는 매우 중요한 콩이 있습니다. GetObject 메소드가 구현되는 한 인스턴스 객체를 생성하는 방법을 정의 할 수 있습니다. 그러나 스프링 내부 의이 Bean의 인스턴스 객체는 객체의 getObject 메소드를 호출하여 사용자의 맞춤형 객체를 얻을 수 있으므로 스프링에 대한 확장 성을 제공 할 수 있습니다. Spring의 팩토리 비앤 자체를 얻는 대상은 완료되고 완료됩니다.
Bean의 인스턴스 개체를 만드는 방법 및 Bean 인스턴스 객체 간의 관련 관계에서 코어 키를 구축하는 방법은 다음 과정의 흐름도입니다.
그림 13. 인스턴스 생성 흐름도
평범한 콩이라면 그는 getbean 방법을 호출하여 직접 인스턴스를 만듭니다. 다음은 시간 -콩 인스턴스 생성의 순차적 맵입니다.
그림 14. 인스턴스 생성 순차적 차트
또 다른 중요한 부분은 Bean 객체 인스턴스 간의 관계를 설정하는 것입니다.
그림 15. 객체 관계 설정
IOC 컨테이너의 확장 지점
또 다른 문제는 이러한 Bean 객체에 특정 확장 성을 갖도록하는 방법입니다. 즉, 일부 작업을 추가 할 수 있습니다. 그렇다면 확장은 무엇입니까? Spring은 이러한 확장을 어떻게 호출합니까?
Spring의 IOC 컨테이너에는 너무 많습니다. BeanFactoryPostProcessor, BeanPostProcessor. 그들은 콩 변덕을 만들고 콩 물체를 만들 때 호출됩니다. 초기화 된 비인과 콩 인스턴스에 의해 만들어지고 파괴 될 때 호출됩니다. 사용자는 이러한 인터페이스에 정의 된 메소드를 구현할 수 있으며 Spring은 적절한 시간에 호출합니다. 다른 하나는 FactoryBean입니다.
이러한 확장 지점은 일반적으로 스프링을 사용하여 스프링을 능숙하게하는 방법과이를 사용하는 방법에 따라 다릅니다. . 다음 은유를 사용하여 설명 할 수 있습니다.
우리는 IOC 컨테이너를 하나의 박스와 비교합니다. 그러면 해당 관계는 콩나무이며 기계 제조 모델, 볼 모드는 Bean이며 볼 모드의 볼은 콩의 인스턴스입니다. 앞에서 언급 한 확장은 어디에 있습니까? BeanFactoryPostProcessor는 볼 모델의 생성에 해당하며, 수정을 할 수있는 기회, 즉 볼 모드를 수정하는 데 도움이 될 수 있습니다. 초기화 비 및 일회용 비안은 볼 모델의 시작과 끝에 있으며 일부 준비 및 테일링 작업을 완료 할 수 있습니다. BeanPostProcessor를 사용하면 볼 모드를 적절히 수정할 수 있습니다. 마지막으로, 마법의 공 모델 인 FactoryBean이 있습니다. 이 볼 모드는 사전에 없지만이 공 모델의 모양을 결정할 수 있으므로, 그가 만든 공은 당신이 원하는 공이어야합니다. 당신이 원하는 공
IOC 컨테이너를 사용하는 방법
스프링 컨테이너의 건축 과정의 이전 도입, 스프링은 우리에게 무엇을 할 수 있고, Spring의 IOC 컨테이너는 무엇을 할 수 있습니까? 스프링이 작동하지 않으면 먼저 IOC 컨테이너를 구축해야합니다.
IOC는 실제로 Rubik 's Cube를 만들고 있습니다. 그렇다면 우리는 어떻게 참여합니까? 이것이 봄에 일부 확장을 이해하기 위해 앞서 말한 것이며, 우리는 연장 지점을 달성함으로써 스프링의 공통 동작을 바꿉니다. 우리가 원하는 성격 결과를 얻기 위해 확장 지점을 달성하는 방법에 대해서는 봄에 많은 예가 있습니다. 참조에 사용됩니다.
봄에 AOP 기능에 대한 자세한 설명
동적 프록시 구현 원리
Spring의 AOP를 이해하려면 Dynamic Proxy를 기반으로 AOP가 구현되기 때문에 Dynamic Agency의 원칙을 먼저 이해해야합니다. 동적 에이전트는 JDK 자체로 시작해야합니다.
대행사 클래스 입구 인 JDK의 Java.Lang.Reflet 패키지 아래에 프록시 클래스가 있습니다. 이 클래스의 구조 :
그림 16. 프록시 구조 구조
위의 그림에서 네 가지는 공개 방법입니다. 마지막 방법 NewProxyInstance는 프록시 객체를 만드는 방법입니다. 이 방법의 소스 코드는 다음과 같습니다.
목록 6.proxy.newproxyinstance
공개 정적 개체 NewProxyInstance (클래스 로더 로더, 클래스> [] 인터페이스, invocatchhandler h)는 불법적 인 {if (h == null) {th Row New NullPointerException (); = cl.getConstructor (ConstructorParams) return (객체) conds. );} catch (InstantiationException e) {새 인터넷 던지기 (e.toString ());} 새 인터넷 (e.toString ());}}이 방법에는 3 가지 매개 변수가 필요합니다. 클래스 로더는 프록시 클래스 로더 클래스를로드하는 데 사용되며 에이전트 클래스는 동일한 로더 클래스입니다. 인터페이스는 표현 될 인터페이스입니다. InvocationHandler는 프록시 인터페이스의 메소드 외에 사용자가 사용자 정의하는 사용자의 작업을 실행하는 데 사용됩니다. 사용자 호출 대상 방법은 InvacationHandler 클래스 호출에 정의 된 고유 메소드로 표시됩니다. 이것은 나중에 자세히 설명합니다.
프록시가 어떻게 프록시 클래스를 생성하는지 봅시다. 아래에 표시됩니다.
그림 17. 프록시 객체 생성
실제로, 상기 그림에서 에이전트 클래스가 proxygenerator의 생성 프록시 클래스의 방법에 있음을 발견 할 수 있습니다. proxygientor 클래스는 Sun.Mist에 랩핑됩니다.
다음과 같이 인터페이스가있는 경우 :
목록 7. SimpleProxy 클래스
public interface simpleproxy {public void sizemethod1 ();에이전트가 생성 한 클래스 구조는 다음과 같습니다.
목록 8. $ proxy2 클래스
Public Class는 Java.lang.rang.reflect.proxy를 구현합니다. 메소드 M3;
이 클래스의 메소드는 호출 방법을 호출하며 각 방법은 속성 변수에 해당합니다. 이것이 전체 에이전트가 실현되는 방식입니다.
Springaop을 달성하는 방법
이전 에이전트의 원칙에서 프록시의 목적은 대상 메소드가 호출 될 때 호출 핸들러 클래스의 호출 메소드를 실행할 수 있으므로 호출 핸들러에서 기사를 만드는 방법이 AOP 구현의 핵심이라는 것을 알고 있습니다. .
Spring의 AOP 구현은 AOP Alliance를 준수하기위한 계약입니다. 동시에, Spring은 그것을 확장하여 Pointcut 및 Advisor와 같은 일부 인터페이스를 추가하여보다 유연하게 만들었습니다.
아래는 JDK Dynamic Proxy의 클래스 다이어그램입니다.
그림 18.JDK 동적 프록시 클래스 다이어그램
위의 그림은 AOP Alliance 정의에 의해 정의 된 인터페이스를 명확하게 보여줍니다. Spring이 AOP Alliance를 확장하는 방법에 대해 논의하지 마십시오. 먼저 Spring이 에이전트 클래스를 실현하는 방법을 살펴 보겠습니다.
목록 9. 프록시 콩을 구성하십시오
<bean id = "testbeansingleton"> <property name = "proxyinterfaces"> value> org.springframework.ap.framework.prototypettests $ testbean value> p roperty> <속성 이름 = "target"> <Ref Local = "testBeantAget" > ref> property> <속성 이름 = "싱글 톤"> value> trueValue> property> <속성 이름 = "interceptors"> <list> <value> testinterceptorvalue> <val ue> testinterceptor2value> list> bean>
구성에서 에이전트의 인터페이스가 설정되어 있고 인터페이스의 구현 클래스가 대상 클래스이며, 여기에서 스프링에 정의 된 다양한 인터셉터는이를 사용하도록 선택할 수 있습니다. 본질
스프링이 어떻게 에이전트를 완성하고 인터셉터를 호출하는지 살펴 보겠습니다.
앞서 언급했듯이 Spring AOP는이 프록시 클래스에서 자체 확장 지점을 달성합니다. 물론 프록시 객체는 프록시 클래스를 통해 동적으로 생성되어야합니다.
다음은 스프링에 의해 생성 된 프록시 객체의 타이밍 차트입니다.
그림 19. 객체 객체의 출현
Spring이 프록시 객체를 생성 한 후 대상 객체에서 메소드를 호출하면 이전에 설명 된 InvocationHandler 클래스의 호출 메소드에 표시됩니다. 여기서 jdkdynamicaopproxy 클래스는 InvocationHandler 인터페이스를 구현합니다.
스프링이 인터셉터를 어떻게 호출하는지 살펴 보겠습니다. 다음은이 과정의 타이밍 차트입니다.
그림 20. 스프링은 인터셉터를 호출합니다
위는 JDK 다이나믹 에이전트도 CGLIB 에이전트를 지원합니다.
봄의 설계 모드 분석
"Webx 프레임 워크의 시스템 아키텍처 및 설계 모델", "Tomcat의 시스템 아키텍처 및 모드 설계 분석"에는 공장 모드, 싱글 모드, 템플릿 모드 등과 같은 스프링에 사용 된 많은 설계 패턴도 있습니다. 이미 소개되었습니다. 여기서 우리는 주로 대행사 모드와 전략 모드를 소개합니다.
프록시 모드
프록시 모드 원리
프록시 모드는 특정 객체에 대한 프록시 오브젝트를 작성하는 것이며 프록시 객체는 원래 객체에 대한 참조를 제어 하고이 프록시 객체의 생성은 원래 객체에 약간의 추가 작업을 추가 할 수 있습니다. 아래는 프록시 모드의 구조입니다.
그림 21. 프록시 모드의 구조
제목 : 초록 테마는 물론 에이전트 객체의 실제 객체를 실현하는 인터페이스입니다.
proxysubject : 추상 테마의 정의 인터페이스 외에도 프록시 클래스는 에이전트 객체의 참조를 보유해야합니다.
RealSubject : 에이전트의 클래스는 대상 객체입니다.
스프링에서 프록시 모드를 구현하는 방법
Spring AOP의 JDK 동적 에이전트는 대행사 모드 기술을 사용하여 달성됩니다. 봄에 프록시 객체의 인터페이스 외에도 org.springframework.aop.springproxy 및 org.springframework.apork.advise도 있습니다. 스프링에서 프록시 모드를 사용하는 생성자는 다음과 같습니다.
그림 22. 프록시 모드의 구조 다이어그램은 배선에 사용됩니다.
$ proxy는 생성 된 프록시 객체이며 주제는 추상 테마이며 프록시 객체는 invocationHandler를 통해 대상 객체에 대한 참조를 유지하는 것입니다.
스프링의 실제 프록시 객체 구조는 다음과 같습니다.
목록 10 프록시 객체 $ proxy4
공개 클래스 $ proxy4는 java.lang.reflect.proxy를 구현합니다. METHOD METHOD .reflect.method m11; java.lang.reflect.method m22; java.lang.reflect.Method m3; java.lang.reflect.Method java.lang.reflect. Method m4; java.lang.reflet.method m19; java .lang.reflect.Method M7; java.lang.reflet.method m15; java.lang.reflet.method m20; left.Method M10; java. LANG.Reflect.Method M1; java.lang.reflect.Method M17; java .lang.reflect.Method M21; java.lang.reflect.Method m0; ava.lang.reflet.method m24; int HashCode (); int indexof (org.SpringFramework.aop.advisor); int interxof (org.aopalliance. aip.advice); ject); java.lang.string tostring (); void sayhello (); void dosomething (); void dosometHing2 (); java.lang.class getProxiedIndIndIndIndIndIndIRFACES (); ProxytargetClass (); Org.SpringFramework.aop .advisor; getadvisors (); void addvisor (int, org.springframework.aip.advisor) Throws org.SpringFramework.aP.framework.aPConfigeXception; void addadvisor (ORG.Sprin gframework.aop.advisor) Throws org.SpringFramework.aop. framework.aPConfigeXception; void SetTargetsource (ORG .springframework.aop.targetsource); ORG.SpringFramework.aop.Targetsource GetTARGETSource (); d (); Boolean IsinterfaceProxied (java.lang.class); Boolean Removeadvisor (org.SpringFramework.aP. advisor );; Boolean SOR, ORG.SpringFramework.aP.Advisor) Throws org.SpringFramework.aop.framework.aPConfigeXception; void addAdvice (ORG.AOPALLIANCE.AOP.ADVICE) Throws org.SpringFramework.aP.framework.aPConfigexception; void addvice (int, org.aopalliance.aop.advic e) Throws org.Springframework.aP.framework.aPConfigeXception; .aop.advice); java.lang.string toproxyconfigstring (); Boolean isfrozen (); void setexposeProxy (Boolean);
策略模式
策略模式原理
The strategy model, as the name suggests, is a strategy to do something. This usually means that there may be multiple methods to complete a certain operation in programming. These methods may have different occasions and may have different adaptation. However, these methods may 사용하십시오.各一个操作方法都当作一个实现策略，使用者可能根据需要选择合适的策略。
下面是策略模式的结构：
图23.策略模式的结构
Context：使用不同策略的环境，它可以根据自身的条件选择不同的策略实现类来完成所要的操作。它持有一个策略实例的引用。创建具体策略对象的方法也可以由他完成。
◆Strategy：抽象策略，定义每个策略都要实现的策略方法
◆ConcreteStrategy：具体策略实现类，实现抽象策略中定义的策略方法
◆Spring中策略模式的实现
◆Spring中策略模式使用有多个地方，如Bean定义对象的创建以及代理对象的创建等。这里主要看一下代理对象创建的策略模式的实现。
前面已经了解Spring的代理方式有两个Jdk动态代理和CGLIB代理。这两个代理方式的使用正是使用了策略模式。它的结构图如下所示：
图24.Spring中策略模式结构图
在上面结构图中与标准的策略模式结构稍微有点不同，这里抽象策略是AopProxy接口，Cglib2AopProxy和JdkDynamicAopProxy分别代表两种策略的实现方式，ProxyFactoryBean就是代表Context角色，它根据条件选择使用Jdk代理方式还是CGLIB方式，而另外三个类主要是来负责创建具体策略对象，ProxyFactoryBean是通过依赖的方法来关联具体策略对象的，它是通过调用策略对象的getProxy (ClassLoaderclassLoader)方法来完成操作。
요약
本文通过从Spring的几个核心组件入手，试图找出构建Spring框架的骨骼架构，进而分析Spring在设计的一些设计理念，是否从中找出一些好的设计思想，对我们以后程序设计能提供一些思路。接着再详细分析了Spring中是如何实现这些理念的，以及在设计模式上是如何使用的。