머리말
Java 개발에 참여한 코더로서 봄의 중요성은 자명합니다. 매일 봄 프레임 워크를 다루고있을 수 있습니다. Spring은 이름이 지정되어 있으며 Java 응용 프로그램의 개발에 봄과 같은 편안함을 가져옵니다. Spring은 모든 Java 개발자가 고급 기술에 도달하는 데 필요한 기초라고 할 수 있습니다. 물론 봄의 기본 원리를 이해하는 것은 봄을 잘 배우는 것이 쉽지 않습니다. 신중하게 공부하는 데 많은 시간과 에너지가 필요하며, 자신의 사고와 이해를 형성하기 위해 실제 프로젝트에서 끊임없이 시행 착오 및 요약합니다. 블로거는 처음에 봄에 대한 매우 얕은 이해를 가졌으며, Du Niang이 프로젝트에서 문제를 일으킬 때 일반적인 방식으로 해결할 수있는 문제에 의존 할 수있었습니다. 그러나 Spring이 Spring과 접촉 한 지 1 년 이상 동안 프레임 워크 시스템에 대한 이해는 매우 혼란스럽고 깊은 기술은 여전히 안개와 같으며 자체 인식과 이해를 형성하지 않았으며, 이는 프로그래밍 기술의 개선에 매우 바람직하지 않습니다. 이를 고려하여, 나는 처음부터 끝까지 Spring 프레임 워크를 체계적으로 진정시키고 배우고 학습 세부 사항을 기록하고 블로그 형태를 통해 기술 지식을 공유하기로 결정했습니다. 좋아, 요점에 가자-
핵심 스프링 프레임 워크 소개
DI (의존성 주입), 종속성 주입 및 우리가 자주 듣는 또 다른 개념은 실제로 IOC (제어 역)과 동일한 기능을 구현하지만 동일한 기능은 다른 관점에서 설명됩니다. 여기의 블로거는 너무 많이 분석하지 않을 것이며, 바이두에 대한 많은 설명이 있습니다. 우리가 알아야 할 것은 의존성 주입이 무엇인지, 종속성 주입이 왜인가입니다. 이 두 가지 점을 이해하기 위해 학습 봄이 사고 측면에서 최고라고 생각합니다.
Spring이 사용되지 않는 경우 - 즉 의존성 주입이 없을 때 Java 응용 프로그램 클래스 간의 상호 기능적 협력을 달성하기가 어렵습니다. 특정 클래스 (a)가 함수를 구현 해야하는 경우 다른 클래스 (b)의 협업에 의존 해야하는 경우 클래스 B 메소드를 사용하여 기능을 완성하기 위해 클래스 A에서 클래스 B 객체를 적극적으로 생성해야합니다 (여기서 정적 메소드 및 기타 상황에 대해 걱정해서는 안됩니다). 이는 클래스 B 객체의 전체 수명주기 관리를 책임지는 클래스 A와 동일합니다. 매우 간단한 경우 한 클래스에서 다른 클래스의 새로운 대상에 문제가 없지만 복잡한 응용 프로그램 클래스와 클래스 간의 협력 관계는 종종 다자간입니다. 우리는 클래스 함수의 구현이 협력하기 위해 의존 할 대체 객체의 수를 모릅니다. 따라서 클래스에서 객체를 생성하고 객체의 전체 수명주기를 관리하면 높은 코드 커플 링 및 상상할 수없는 복잡성이 발생합니다. 따라서, 우리가 객체의 수명주기를 관리를위한 타사 구성 요소에 넘겨 줄 수 있고, 클래스에 다른 객체가 필요할 때 타사 구성 요소가 직접 생성 될 것이라고 상상해보십시오. 이러한 방식으로, 클래스는 다른 클래스 객체의 수명주기를 관리하지 않고 자체 기능의 구현에만 초점을 맞출 수 있으며, 그러한 클래스의 기능은 훨씬 간단합니다. 예, 봄 이이 타사 구성 요소라는 것을 이해해야합니다. 우리는 단지 스프링 (컨테이너)에게 어떤 객체를 관리 해야하는지 알리면 스프링 프레임 워크가 객체를 만드는 방법에 대해 신경 쓰지 않아도됩니다. 이러한 방식으로, 특정 클래스 A가 클래스 B 객체를 요구할 때, 클래스 B가 선언되어 스프링 컨테이너 관리에 전달 된 경우, 프로그램이 클래스 A로 실행되고 클래스 B가 필요할 때 스프링 컨테이너는 클래스 B 객체를 클래스 A에 주입하여 비즈니스 기능을 완료하는 데 도움을줍니다. 타사 구성 요소의 종속성 주입을 통해 객체는 더 이상 클래스 간의 종속성을 생성하고 관리 할 필요가 없습니다. 인터페이스 주입, 시공 방법 주입, 세터 방법 주입 등과 같은 물체의 종속성 주입을 생성하는 방법에는 여러 가지가 있습니다. 의존성 주입이 필요한 이유에 관해서는, 위의 기사는 이미 그것을 매우 명확하게 설명했습니다. 코드의 구성 요소 간의 커플 링을 줄이려면 먼저 간단한 예제를 사용하여 객체 관리에 대한 종속성 주입의 이점을 직관적으로 경험해야합니다.
공공 계급 남자는 인간 {private qqcar car; public man () {this.car = new qqcar (); } @override public void xiabibi () {} public void drivecar () {car.drive (); }}인터페이스 차량의 두 가지 구현, 즉 메르세데스-벤츠와 QQ 자동차가 있습니다. 위의 Man 및 QQCar 코드에서 베테랑 드라이버는 생성자를 통해 QQ 자동차 객체 만 만들어 QQ 자동차만을 운전할 수 있습니다. 그렇다면 베테랑 운전자는 메르세데스-벤츠를 운전하고 싶다면 어떻게해야합니까? 메르세데스-벤츠 물체를 재현 해달라고 부탁합니까? 이러한 고도로 결합 된 코드는 무력한 것처럼 보이므로 객체를 주입하여 위의 코드를 약간 개선 할 것입니다.
공공 계급 남자는 인간을 구현합니다. {개인 자동차 자동차; 공개 남자 (자동차 자동차) {this.car = 자동차; } @override public void xiabibi () {} public void drivecar () {car.drive (); }}위의 코드는 생성자 인터페이스 주입을 통한 다형성 특성을 기반으로 특정 객체를 차단하므로 베테랑 운전자가 원하는 것을 운전할 수 있습니다. 이것이 의존성 주입의 이점입니다.
AOP (Aspect Oriented Programming), 얼굴 지향 프로그래밍. 일상 개발에서 특정 비즈니스 기능을 완료하면 많은 코드를 작성합니다. 코드를 최적화 할 때 실제로 비즈니스를 완료하는 코드는 두 문장 일뿐 아니라 나머지는 비즈니스 의이 부분과 관련이 없습니다. 특정 기술 코드를 구현하기 위해 완전히 추출됩니다. 따라서 당연히 도구 클래스로 추출하여 도구 방법을 호출 할 때 사용하는 모든 것이 정상입니다. 조금 더 높이 봅시다. 관련 비즈니스 기능을 완료하는 것 외에도 각 비즈니스 모듈의 기능 구성 요소에는 로그, 트랜잭션 및 보안 관리와 같은 추가 작업이 포함됩니다. 이것들은 모듈의 핵심 기능이 아니지만 필수 불가결합니다. 이러한 추가 기능이 코드에 추가되면 비즈니스 시스템의 각 구성 요소가 너무 반복적으로 나타나고 비즈니스 코드가 혼란스럽고 순수하지 않은 것처럼 보이게합니다. 현재, 당신은 신에게 묻습니다. 비즈니스 코드는 비즈니스 구현에만 집중하고 로그, 거래 등과 같은 관련없는 것들을 무시할 수 있습니까? 오, 하나님은 괜찮다고 말씀하셨습니다. 그래서 AOP가있었습니다. 의존성 주입의 목적이 협력 구성 요소를 비교적 느슨한 커플 링 상태로 유지하는 경우, AOP는 재사용 가능한 구성 요소를 형성하기 위해 애플리케이션에 걸쳐 확산 된 기능을 분리합니다. 평신도의 용어에 따르면 로그, 트랜잭션 등은 모두 재사용 가능한 구성 요소입니다. 비즈니스 코드의 여러 부분에 흩어져있는 로그, 트랜잭션, 보안 및 기타 기능 코드를 완전히 추출하고 별도의 도구 구성 요소가 될 수 있습니다. Spring의 구성에서 기능 섹션으로 선언 한 다음이 재사용 가능한 구성 요소를 어디에 사용하고 싶은지 Spring에게 알리십시오. 이것은 얼굴 지향 섹션에 대한 나의 간단한 해석입니다. 이 기사는 소개 일 뿐이므로 블로거는 개념을 간단히 설명하고 특정 코드 또는 구성 구현을 만들지 않습니다. 후속 블로그 게시물에 표시됩니다. 살펴보기에 오신 것을 환영합니다.