왜
출생 초기에 봄을 만드는 주요 목적은보다 헤비급 엔터프라이즈 수준의 Java 기술, 특히 EJB를 대체하는 것이 었습니다. EJB와 비교하여 Spring은 더 가볍고 간단한 프로그래밍 모델을 제공합니다.
무엇
Spring은 Rodjohnson이 처음 만든 오픈 소스 프레임 워크입니다. Spring은 엔터프라이즈 수준의 응용 프로그램 개발의 복잡성을 해결하기 위해 만들어졌습니다. Spring을 사용하면 간단한 Javabeans가 EJB만이 이전에 달성 할 수있는 것들을 구현할 수 있습니다. Spring은 서버 측 개발에만 국한되지 않으며 모든 Java 응용 프로그램은 단순성, 테스트 가능성 및 느슨한 커플 링 측면에서 Spring의 혜택을 누릴 수 있습니다.
오늘날 Spring은 모바일 개발, 소셜 API 통합, NOSQL 데이터베이스, 클라우드 컴퓨팅 및 빅 데이터에 참여하고 있습니다. 시간이 지남에 따라 EJB는 의존성 주입 (DI) 및 AP (Aspect-Oriented Programming)의 개념을 채택했습니다. 요컨대, Spring의 가장 근본적인 임무는 Java 개발을 단순화하는 것입니다.
어떻게
Java 개발의 복잡성을 줄이기 위해 Spring은 4 분의 주요 전략을 채택합니다.
Pojo를 기반으로 한 가볍고 최소 침습적 프로그래밍
섹션 및 컨벤션을 기반으로 한 선언 프로그래밍 섹션 및 템플릿을 통해 스타일 코드를 줄입니다.
포조 잠재력
많은 프레임 워크는 응용 프로그램이 클래스를 상속하거나 인터페이스를 구현하도록 강요하여 응용 프로그램이 프레임 워크에 바인딩되어 침습적 인 프로그래밍으로 코드 블록을 재사용 할 수 없습니다. Spring은 자체 API로 인해 애플리케이션 코드를 망치지 않기 위해 노력합니다. 봄에 제작 된 응용 분야에서 클래스는 일반적으로 스프링을 사용하는 표지판의 흔적이 없습니다.
공개 클래스 Helloworldbean {public String sayhello () {return "Hello World"; }} 위의 예제 코드는 매우 간단하고 일반적인 Java 클래스 (POJO)를 나타냅니다. 당신은 그것이 스프링 구성 요소라고 말할 수 없습니다. Spring의 비 침습적 프로그래밍은이 클래스에 반영되어 Spring Applications 및 비 스프링 애플리케이션에서 역할을 수행 할 수 있습니다. 이 코드는 실제로 Spring의 기능을 반영하지 않으며 다음 지식이 여전히 필요합니다.
종속성 주입 (클래스 자체 주입)
복잡한 프로그래밍 기술 또는 설계 패턴 개념으로 발전했지만 의존성 주입은 봄에는 그다지 높지 않습니다. 이것은 봄에 이해되며 종속성을 주입합니다. 실질적인 의미를 가진 응용 프로그램을 사용하려면 여러 클래스가 서로 협력하여 특정 비즈니스 논리를 완료해야합니다. 전통적인 관행은 각 객체가 그 자체와 관련된 객체에 대한 참조를 관리하는 책임이 있다는 것입니다 (이 관련 객체는 봄에 표현 된 객체에 의존하는 객체입니다).
다음 코드를 고려하십시오
/** 입을 다루기 어려운 클래스 이름은 저자가 시뮬레이션 된 장면에 맞게 특별히 지명되었습니다. */public class damselrescuingknight는 기사 {개인 rescuedamselquest Quest;/*** 생성자에 생성 된 rescuedAmselquest* 이렇게하면 생성자에서 DamselRescuingknight와 RescuingDamselquest가 함께 만들어집니다. empermonquest () {quest.embark ();}} 커플 링에는 양면이 있습니다. 한편으로, 엄격하게 결합 된 코드는 테스트, 재사용 및 이해하기가 어렵고 "Goblin과 싸우는"유형 버그가있을 것입니다. 반면에 어느 정도의 커플 링이 필요하며 다른 클래스는 적절한 방식으로 상호 작용해야합니다.
문제가 발생하므로 봄은 어떻게 해결 되었습니까?
스프링에서 의존성 주입 (DI)을 통해 객체 간의 종속성은 객체를 생성 할 때 각 객체를 조정하는 시스템의 타사 구성 요소에 의해 설정됩니다. 다시 말해서, 객체는 자체적으로 종속성을 생성하거나 관리하지 않고 내부 속성을 관리하면되며 종속성은 필요한 객체에 자동으로 주입됩니다.
/***이 기사는 2016/8/25에 Wung에 의해 만든 소녀를 구출하기 위해 이전의 작업 대신 다양한 모험 과제를 수행 할 수 있습니다. */public class braveknight는 기사 {개인 퀘스트 퀘스트;/*** Braveknight가 자체적으로 모험 유형을 만들지 않지만 건설 중 매개 변수로 모험 작업을 전달합니다.* 이것은 의존성 주입의 방법 중 하나입니다 : 생성자 주입*/public braveknight (Quest Quest) {quest = quest;} public void avarkonquest ()}}}}}}}}}}. Braveknight는 특정 퀘스트 구현과 결합되지 않습니다. 작업이 퀘스트 인터페이스를 구현하는 한 어떤 유형의 모험이든 상관 없습니다. 이것은 느슨한 커플 링의 목적을 달성합니다
객체가 인터페이스를 통한 종속성 만 나타내는 경우,이 종속성은 객체 자체가 인식하지 않고 다른 콘크리트 구현으로 대체 될 수 있습니다.
이제 실질적인 의미를 주입합시다
위의 코드의 경우 Brave Knight에 특정 구현으로 모험 작업을 주입합니다.
/** Slaying Dragons의 모험 임무 (이 저자는 좋은 2 등)*2016/8/25에 Wung에 의해 만들어졌습니다. */public class slaydragonquest Quest {private printstream stream; public slaydragonquest (printstream stream) {this.stream = stream;} public void embark () {stream.print ( "Slay the Dragon");}}이제 문제는 Slaydragonquest에서 인쇄물 객체를 주입하는 방법, Braveknight에서 의존하는 퀘스트 객체를 주입하는 방법입니다. 앞서 언급 한 스프링은 이러한 종속성을 중심으로 관리하며 응용 프로그램 구성 요소 간의 협업을 만드는 동작은 일반적으로 어셈블리 (배선), 즉 주입이라고합니다. Spring은 나중에 더 자세히 소개 할 다양한 어셈블리 방법을 제공합니다. 여기에서는 XML과 Java 주석을 기반으로 한 어셈블리를 간단히 소개합니다.
<!- 이것은 어셈블리 프로세스입니다. SlaydragonQuest를 "퀘스트"라는 콩으로 선언하십시오. 생성자 주입이므로 생성자 ARG 속성 값을 사용하여 주입 된 값을 나타냅니다. 이 프로세스는 이전 문제를 해결합니다. printstream 객체를 Slaydragonquest 객체에 주입합니다-> <bean id = "quest"> <constructor-arg value = "#{t (system) .out}"> </constructor-arg> </bean> <!-이 과정은 위와 같습니다. Braveknight는 "Knight"라는 콩을 선언합니다 (이 이름은 반드시 사용되지는 않습니다). Braveknight의 생성자 매개 변수는 퀘스트 유형이어야합니다. 이때, 다른 콩이 기준에 전달되는데, 이는 위의 "퀘스트"라는 이름의 콩의 참조입니다. 현재 Braveknight의 생성자 주입도 완료됩니다.> <Bean id = "Knight"> <Constructor-Arg ref = "Quest"> </protuctor-arg> </bean>Spring은 XML의 대안으로 사용할 수있는 Java 기반 구성을 제공합니다.
/** Java 기반 구성 파일은 2016/8/26에 Wung에 의해 생성 된 객체*의 어셈블리를 구현합니다. */ @configurationPublic Class KnightConfig {@bean public knight () {return new braveknight (quest ()); } @bean public quest quest () {return new slaydragonquest (System.out); }}효과는 동일하며 특정 설명은 다음 장에 자세히 설명되어 있습니다. 다시 검토합시다. Spring은 객체 간의 종속성을 자동으로 관리 할 것이라고합니다. 그러므로 이런 종류의 관리자는 무엇입니까? 답은 응용 프로그램 컨텍스트이며, 콩의 정의를로드하고 조립할 수있는 스프링 용 컨테이너입니다. 스프링 애플리케이션 컨텍스트는 객체의 생성 및 조립에 대해서만 책임이 있습니다. 실제로,이 컨텍스트의 차이를 구현하는 방법에는 여러 가지가 있으며,로드 구성의 차이 만 있습니다. 구성을로드하는 방법을 살펴 보겠습니다.
Public Class Knightmain {public static void main (String [] args) {AnnotationConfigApplicationContext Context = new AnnotationConfigApplicationContext (KnightConfig.class); // 콩의 정의는 구성 파일에서 얻을 수 있습니다. Knight Knight = Context.getBean (Knight.Class); Knight.embarkonQuest (); context.close (); }}얼굴 절단을 바릅니다
DI는 협업 소프트웨어 구성 요소를 느슨하게 연결할 수 있지만 Facet 프로그래밍을 사용하면 응용 프로그램 전체에서 기능을 분리하여 재사용 가능한 구성 요소를 형성 할 수 있으며보다 구체적으로는 소프트웨어 시스템이 초점을 맞추기 위해 노력하는 기술입니다. 초점은 무엇입니까? 로깅, 거래 관리 및 보안 관리와 같은 시스템 서비스는 종종 비즈니스 로직 자체가있는 다른 구성 요소에 통합되어야합니다. 이러한 시스템 서비스는 일반적으로 시스템의 여러 구성 요소에 걸쳐 여러 곳에서 재사용되기 때문에 크로스 절단 초점이라고합니다. 간단히 말해서, 여러 다른 구성 요소에서 재사용 해야하는 서비스를 추출하지만 사용 방법은 무엇입니까? 실제로, 방법을 사용할 때 사용 해야하는 장소에 메소드를 삽입하는 것입니다. 그러나이 용어 "섹션"에 따르면 재사용 된 구성 요소를 섹션으로 추출하고 필요할 때 구성 요소를 통해 섹션을 절단하는 것으로 표현되어야합니다. 따라서 이러한 방식으로 핵심 응용 프로그램은 이러한 섹션의 존재를 알 필요가 없으며 섹션은 비즈니스 로직을 핵심 응용 프로그램에 통합하지 않습니다.
/** 가수 수업은 기사들, 즉 2016/8/26에 Wung에 의해 만든 기사들을 섬기는 데 사용됩니다. */public class minstrel {private printstream 스트림; public minstrel (printstream stream) {this.stream = stream; } // public void singbeforequest () {stream.print ( "시작"); } // public void singafterquest () {stream.print ( "end"); }} 공개 클래스 브레이브 나이트는 기사 {private Quest Quest; private minstrel minstrel;/*** Braveknight가 자체적으로 모험 유형을 만들지 않지만 건축의 매개 변수로 모험 작업을 전달합니다* 이것은 종속성 주입의 방법 중 하나입니다 : Constructor Injection* // public braveknight (Quest = Quest; //} public braveknight) minstrel) {this.quest = quest; this.minstrel = minstrel;} public void allkonquest () {minstrel.singbeforequest (); quest.embark (); minstrel.singafterquest ();}} 현재 용감한 기사는 처형되기 시작했지만, 그의 임무는 위험이 아니라는 것이 아니라 이제는 가수를 관리해야했지만 이제는 관리 해야하는 범주에 속하지 않아야한다는 것을 알았습니다. 따라서 섹션의 아이디어를 사용하여 가수의 찬양 행동을 추출하고 섹션이되어야합니다. Cavaliers가 위험을 감수하기 전에이 섹션은 Singbeforequest 메소드를 실행하고 위험 후 SingAfterquest 메소드를 실행합니다. 따라서 이것은 기사가 칭찬 할 필요가없는 코드를 깨닫고 가수는 기사의 대상에 존재하지 않습니다. 그는 기사를 칭찬 할뿐만 아니라 다른 사람들 이이 섹션을 사용하여 입장하는 한 누군가를 칭찬 할 것입니다.
<!-섹션으로서의 MinStrel로 위의 ID로 Bean을 구성하는 것은 실제로 싱어를 섹션으로 구성하는 것임을 의미합니다.-> 측면 ref = "minstrel"> <!-진입 점을 정의하는 것, 즉 섹션을 사용하는 위치, 즉 Execution = "execution ( * * .embarkonquest (..))은 여기서 execter expression 언어가 될 것입니다. 그리고 진입 포인트 절단 전후에 노트 실행-> </aop : after> </aop : prever> </aop : pointcut> </aop : </aop : config>
상황은 Minstrel이 여전히 독립적 인 pojo이며, Spring의 맥락은 그것을 섹션으로 바꿨습니다. 가장 중요한 것은 기사 가이 섹션의 존재를 전혀 모른다는 것입니다. 이것은 단지 작은 밤 일 뿐이며 실제로 많은 중요한 일을 할 수 있습니다.
템플릿을 사용하여 스타일 코드를 제거하십시오
JDBC를 사용하여 데이터베이스에 쿼리 데이터에 액세스 할 때 완전한 프로세스에는 연결을 설정하고 명세서 개체 생성, 결과 세트 처리, 쿼리 및 다양한 연결을 종료 해야하는 상황이 있습니다. 또한 다양한 예외가 캡처 된 다음 다양한 시나리오의 쿼리에는 그러한 힘든 반복이 필요합니다. JDBC만이 이와 같은 스타일 코드가 많이있는 유일한 경우 일뿐입니다. Spring은 Spring의 jdbctemplate과 같은 템플릿 캡슐화를 통해 스타일 코드를 제거하는 것을 목표로합니다.
콩을 수용하십시오
스프링 기반 애플리케이션에서 응용 프로그램 객체는 스프링 컨테이너에 거주하며, 이는 조립 된 객체를 생성하고 수명주기를 관리하는 데 책임이 있습니다. 그래서 스프링 컨테이너는 무엇입니까? 하나의 컨테이너는 하나만 있습니다. Spring에는 여러 컨테이너 구현이 제공됩니다. 기본적인 DI 지원을 제공하기위한 가장 간단한 컨테이너 인 Bean Factories의 두 가지 범주로 나뉩니다. 응용 프로그램 컨텍스트는 비교적 발전되었으며 응용 프로그램 프레임 워크 수준 서비스를 제공합니다. 대부분의 경우 응용 프로그램 컨텍스트가 더 인기가 있습니다.
응용 프로그램 컨텍스트는 구성을로드하는 여러 가지 방법으로 나뉩니다.
다양한 스프링 기능
요약
Spring은 개발을 단순화 할 수있는 프레임 워크 기술이며 핵심 콘텐츠는 DI 및 AOP입니다.
위의 내용은이 기사에 대한 가십입니다. 봄의 전체 내용을 점차적으로 이해합니다. 모든 사람에게 도움이되기를 바랍니다. 관심있는 친구들은이 사이트를 계속 참조 할 수 있습니다.
SpringMVC 시작 예제
구성 파일을 사용하여 속성 값을 주입하고 스프링의 @Value에 대한 코드에 대한 자세한 설명
스프링 통합 Redis 상세 코드 샘플
단점이 있으면 메시지를 남겨 두십시오.