Programing/Spring

[Spring] 스프링 특징

쿠크 2021. 4. 22. 15:34

1.경량 컨테이너로서 자바의 객체를 Spring이 직접 관리한다.

각각의 객체 생성과 소멸과 같은 라이프 사이클을 스프링이 대신 관리해주며, 스프링으로부터 객체를 얻어올 수 있다.

2.제어 역행(IOC:Inversion of Control)

  • 애플리케이션 간의 느슨한 결합을 도모
  • 컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어 필요에 따라 스프링에서 사용자의 코드를 호출

3.의존성 주입(DI:Dependency Injection)

  • 각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜준다.
  • 객체에 객체가 필요로하는 다른 객체를 생성자, 새터를 통해서 주입하는 것
  • 배터리일체형 핸드폰과 분리형 핸드폰의 차이 -> 분리형이 훨씬 유지보수가 쉽다.

4.관점지향 프로그래밍(AOP:Aspect-Oriented Programming)

  • 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있다.
  • interceptor, Filter와 비슷
  1. 애플리케이션 객체의 생명 주기와 설정을 포함하고 관리한다는 점에서 일종의 컨테이너라고 할 수 있다.
  • iBatis, myBatis나 Hibernate 등 완성도가 높은 데이터베이스처리 라이브러리와 연결 할 수 있는 인터페이스를 제공한다.

6.트랜잭션 관리 프레임워크

  • 추상화된 트랜잭션 관리를 지원하며 설정파일(xml, java, properties 등)을 이용한 선언적인 방식 및 프로그래밍을 통한 방식을 모두 지원
  1. 모델-뷰-컨트롤러 패턴(MVC패턴)
  • 웹 프로그래밍 개발 시 거의 표준적인 방식인 Spring MVC라 불리는 MVC패턴을 사용한다.
  • DispatcherSevlet이 Controller 역할을 담당하고 각종 요청을 적절한 서비스에서 분산시켜주며 이를 각 서비스들이 처리를 하여 결과를 생성하고 그 결과는 다양한 View를 통해서 사용자에게 보여진다.

8.배치 프레임워크

  • 스프링은 특정 시간대에 실행하거나 대용량의 자료를 처리하는데 쓰이는 일괄처리(Batch Processing)을 지원하는 배치 프레임워크를 제공한다. 기본적으로 스프링 배치는 Quartz기반으로 동작한다.
  1. 프로비저닝(Provisioning)
  • 인프라에서 자주 나오는 용어, 사전적인 의미로는 공급, 준비, 대비, 식량이란 의미로 IT에서 의미는특정 서비스를 제공받기 위해 서비스 실행부터 시작해 서비스를 제공받기 전 단계까지 처리되는 일련의 절차를 말한다.

즉, 사용자 혹은 비즈니스 요구사항에 맞게 할당, 배치, 배포하여 시스템을 사용가능하도록 준비하는 절차를 말한다.

예를 들어서 설명하자면,

- A서버 - 회원정보를 입력받아 저장하는 서버
- B서버 - 가입된 회원정보를 토대로 그 회원의 주 관심사를 분석하는 서버

이때, 회원 가입을 하면 A서버에 '홍길동'회원의 정보가 들어간다. 그때, B서버는 새로 가입한 홍길동이라는 정보를 가지고 있지 않다.
그래서 A서버는 B서버의 DB중에서 프로비저닝 테이블에 새로 들어온 홍길동의 회원정보를 넣어주는 것이다. 그러면 B서버는 프로비저닝 테이블을 일정 주기마다 읽어서 새로 가입한 사람을 알게 되고, B서버쪽 DB 회원 테이블에도 그 정보를 넣어준다.
이렇게 A서버에서 정보를 내려받아서 B서버가 동기화하는걸 프로비저닝이라고 생각하면된다.

프로비저닝의 유형이 다음과 같이 여러 개 있다.

  • 서버 자원 프로비저닝
    서버의 CPU, Memory 등의 자원을 할당 또는 적절하게 배치하여 운영이 가능하도록 준비하는걸 서버 자원 프로비저닝이라 한다.
  • OS 프로비저닝
    OS 를 서버에 설치하고, 구성 작업을 해서 OS가 동작 가능하도록 준비해두는걸 OS 프로비저닝이라고 한다.
  • 소프트웨어 프로비저닝
    소프트웨어(WAS, DBMS, 어플리케이션 등) 를 시스템에 설치 배포하고 필요한 구성 셋팅 작업을 해서 실행 가능하도록 준비하는걸 소프트웨어 프로비저닝이라고 한다.
  • 스토리지 프로비저닝
    낭비되거나 사용되지 않는 스토리지를 식별하고 공통 풀에서 옴긴 후 스토리지에 대한 요구가 접수 되면 관리자는 공통 풀에서 스토리지를 꺼내 사용 효율성을 높일 수 있는 인프라 구축 가능하도록 하는걸 스토리지 프로비저닝이라고 한다.
  • 계정 프로비저닝
    신입사원이 입사하거나 조직내에서 인사 이동을 하거나 직무변경이 발생해 사용자가 접근하는 자원(Resource)의 범주가 변경되었을 때 HR담당자와 IT관리자는 승인절차 밟은 후 e-mail ,그룹웨어 ,ERP등 다양한 어플리케이션에 필요한계정을 생성하거나 접근권한을 변경해주데, 이러한 일련의 과정을 계정 프로바이저닝이라 한다.

2. 제어역전(IoC) / 의존관계 주입(DI)

IoC와 DI는 스프링의 가장 기본이 되는 기술이자 스프링의 핵심 개발 원칙이기도 하다. 나머지 두가지 기술인 AOP와 PSA도 IoC/DI에 바탕을 두고 있다.
3대 기술은 아니지만 자주 등장하는 템플릿/콜백 패턴이 적용된 부분도 IoC/DI가 그 핵심 원리이다.

2-1-1. 객체간의 결합도(Coupling)

어떤 특정 객체가 존재하거나 기능하기 위해서 반드시 존재해야하는 것을 결합도라고 한다. java에서는 이러한 의존성은 new나 setter를 통해서 이루어지게 된다.

class Player {  
        private Weapon weapon;


        Player(){

        }

        void setWeapon(){
            this.weapon = new Weapon();
        }

}

이러한 방식은 강결합(Tightly Coupled)으로 묶여지면서 코드의 유연성을 떨어트리고 코드의 중복 및 가독성을 떨어뜨리는 원인이 된다. 예를 들어 만약 무기가 칼,총,창 등 여러가지의 무기가 있다면, 프로그래머는 이러한 무기들을 if-else를 통해서 중복된 코드를 작성하게 된는데, 그렇기 때문에 결합도를 낮추고 중복을 낮추며 유지보수를 편하게 하기 위해서 아래와 같은 방식으로 코드를 짜야한다.

class Knife implements Weapon{  
        public void useWeapon() {  
                System.out.println("Use Knife");  
        }  
}

class Gun implements Weapon{  
        public void useWeapon() {  
                System.out.println("Use Gun");  
        }  
}

class Spike implements Weapon{  
        public void useWeapon() {  
                System.out.println("Use Spike");  
        }  
}

interface Weapon {  
        void useWeapon();  
}

public class Player {  
        private Weapon weapon;  
                Player(){

    } 

        public void setWeapon(Weapon weapon) { 
            this.weapon = weapon; 
        } 
        public void usePlayerWeapon() { 
            weapon.useWeapon(); 
        } 


}

public class Main {  
        public static void main(String\[\] args) {


        Player player = new Player(); 

        player.setWeapon(new Gun());
        player.usePlayerWeapon(); 

           player.setWeapon(new Spike()); 
        player.usePlayerWeapon(); 

        player.setWeapon(new Knife()); 
        player.usePlayerWeapon(); 
    } 
}  
/* Result :  
Use Gun  
Use Spike  
Use Knife  
*/

}  
/* Result :  
Use Gun  
Use Spike  
Use Knife  
*/

위의 코드와 같이 설계되면 특정 상황이나 필요에 따라서 코드 상에 if-else문으로 구현하지 않고 interface에 맞춰서 인스턴스를 갈아 끼우기만 하면 되므로 코드가 유연해지고 가독성이 높아지면서 코드의 중복이 필연적으로 제거가 된다.

2-1-1. IoC컨테이너

스프링에서는 이와 같이 결합도를 낮추기 위해서 컨테이너라는 곳에서 Bean이라는 인스턴스 형태로 관리 한다.

컨테이너는 이러한 Bean들을 설정파일들로부터 설정값을 읽어드리고 컨테이너가 생성될 시 자동적으로 해당 객체에 IoC원칙하에 의존성을 주입한다.

2-2. 의존성 주입(DI)

class Knife implements Weapon{

    public void useWeapon() {
        System.out.println("Use Knife");
    }
}

class Gun implements Weapon{

    public void useWeapon() {
        System.out.println("Use Gun");
    }
}

class Spike implements Weapon{

    public void useWeapon() {
        System.out.println("Use Spike");
    }
}

interface Weapon {

    void useWeapon();
}

public class Player {

    private Weapon weapon;

    Player(){
    }

    public void setWeapon(Weapon weapon) {
        this.weapon = weapon; 
    }

    public void usePlayerWeapon() {
        weapon.useWeapon();
    }
}

public class Main {

    public static void main(String[] args) {
        /**
         * 의존성 주입을 통해 의존 요소들을 쉽게 갈아 끼울 수 있다.
         */
        Player player = new Player();

        player.setWeapon(new Gun());    // Player에 Gun 객체를 통한 의존성 주입
        player.usePlayerWeapon();

        player.setWeapon(new Spike()); // Player에 Spike 객체를 통한 의존성 주입
        player.usePlayerWeapon();

        player.setWeapon(new Knife()); // Player에 Knife 객체를 통한 의존성 주입
        player.usePlayerWeapon();
    }
}

실제로 일체형이 아닌 분리형 객체를 통해서 손쉽게 Player라는 객체의 속성을 다른 객체로 매번 바꿀 수 있다. 즉, 유지보수하는데 있어 편하다.

그리고 Spring에서는 스프링 컨테이너가 bean라는 객체를 관리해주므로 스프링이 알아서 IoC원칙 하에서 객체들과 의존성을 관리해준다.

아래에는 Spring에서 java가 아닌 xml을 통해서 객체를 선언하고 의존성을 주입하는 방식의 코드이다.

<-- appContext.xml --> 
<-- 스프링 xml 설정파일 --> 
<?xml version="1.0" encoding="UTF-8"?> 
<beans xmlns="http://www.springframework.org/schema/beans"         
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     
    xsi:schemaLocation="http://www.springframework.org/schema/beans     
    http://www.springframework.org/schema/beans/spring-beans.xsd"> 

    <bean id="gun" class="com.tutorial.spring.Gun"/> 
    <bean id="knife" class="com.tutorial.spring.Knife"/> 
    <bean id="spike" class="com.tutorial.spring.Spike"/> 

    <bean id="gunPlayer" class="com.tutorial.spring.Player"> 
        <constructor-arg ref="gun"/> 
    </bean>

    <bean id="knifePlayer" class="com.tutorial.spring.Player"> 
        <property name="weapon" ref="knife"/> 
    </bean>

    <bean id="spikePlayer" class="com.tutorial.spring.Player"> 
        <property name="weapon" ref="spike"/> 
    </bean> 
</beans>

3. AOP(Aspect Oriented Programming)

AOP란 무엇인가?
관점 지향 프로그래밍이라 불리며, 여기서 관점 지향이란 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로 나누어서 보고 그 관점을 기준으로 각각 모듈화하겠다는 것이다. 여기서 모듈화란 어떤 공통된 로직이나 기능을 하나의 단위로 묶는 것을 말한다.

AOP에서 각 관점을 기준으로 로직을 모듈화한다는 것은? 무슨뜻인가?
코드들을 부분적으로 나누어서 모듈화하겠다는 것이다. 이때 코드 상의 다른 부분에서도 반복적으로 쓰는 코드들을 흩어진 관심사(Crosscutting Concerns)라 부른다.

위와 같이흩어진 관심사를 Aspect로 모듈화하고 핵심적인 비즈니스 로직에서 분리하여 재사용하겠다는 것이 AOP의 취지이다.

3-1. AOP의 주요 개념

  • Aspect : 위에서 설명한 흩어진 관심사를 모듈화한 것을 의미하며, 주로 부가기능을 모듈화한다.
  • Target : Aspect를 적용하는 곳(클래스, 메소드)
  • Advice : 실질적으로 어떤 일을 해야할 지에 대한 것, 실질적인 부가기능을 담은 구현체, 어드바이스는 조인포인트와 결합하여 동작하는 시점에 따라 5개로 구분

Before Advice : 조인포인트 전에 실행되는 advice After returning advice : 조인포인트에서 성공적으로 리턴 된 후 실행되는 advice After throwing advice : 예외가 발생하였을 경우 실행되는 advice After advice : 조인포인트에서 메서드의 실행결과에 상관없이 무조건 실행되는 advice, 자바의 finally와 비슷한 역할 Around advice : 조인포인트의 전 과정(전, 후)에 수행되는 advice

  • JointPoint : Advice가 적용될 위치, 끼어들 수 있는 지점, 메서드 전입 지점, 생성자 호출 시점, 필드에서 값을 꺼내올 떄 등 다양한 시점에서 적용이 가능
  • PointCut: PointCut의 상세한 스펠을 정의한 것, 구체적으로 Advice가 실행될 지점을 정의할 수 있다.

4. Servlet

서블릿이란?
server + let 또는 server + applet의 합성어이다.
클라이언트 요청을 처리하고 그 결과를 다시 클라이언트에게 전송하는 서블릿 클래스의 구현 규칙을 지킨 자바 프로그램이다.

servlet을 관리하는 것을 Servlet Container이라고 한다.

4-1. Servlet의 동작과정

순서

1. 사용자가 url 클릭 시 http request를 통해 Servlet Container로 보낸다.

2. Servlet Container는 HttpServletRequest, HttpServletResponse 두 객체를 생성.

3. 사용자가 요청한 url이 어느 servlet에 대한 요청인지 web.xml에서 찾는다.

4. Container는 서블릿 특정 메소드를 호출한다. [GET인지 POST인지에 따라서 doGet() 또는 doPost()를 호출]

5. 특정 메소드는 동적인 페이지를 생성 후 HttpServletResponse객체에 응답을 보낸다.

6. 최종적으로 사용자 웹 브라우저에 요청한 값을 확인할 수 있다.

7. 응답이 끝난 HttpServletRequest, HttpServletResponse 두 객체는 소멸된다.

4-2. Servlet Container

서블릿을 관리해주는 것으로 서블릿 컨테이너는 클라이언트의 요청을 받고, 응담을 할 수 있게, 웹 서버와 소켓을 만들어 통신해주는데, 대표적으로 톰켓(Tomcat)이 있다.

그렇다면 Servlet Container의 역할이 무엇일까요?

  • 웹 서버와의 통신 지원
  • 서블릿 컨테이너는 서블릿과 웹서버가 손쉽게 통신할 수 있게 해줍니다. 일반적으로 우리는 소켓을 만들고 listen, accept등을 해야하지만 서블릿 컨테이너는 이러한 기능을 API로 제공하여 복잡한 과정을 생략할 수 있게 해줍니다.
  • 서블릿 생명주기(Life Cycle)관리
  • 서블릿 컨테이너는서블릿의 생성과 소멸을 관리합니다. 서블릿 클래스를 로딩하여 인스턴스화하고, 초기화 메소드를 호출합니다. 또한 서블릿이 생명을 다 한 순간에는 적절하게Garbage Collection을 진행하여 편의를 제공합니다.
  • 멀티쓰레드 자원 및 관리
  • 서블릿 컨테이너는 요청이 올 때 마다 새로운 자바 쓰레드를 하나 생성하는데, HTTP 서비스 메소드를 실행하고 나면, 쓰레드는 자동으로 죽게됩니다. 원래는 쓰레드를 관리해야 하지만 서버가 다중 쓰레드를 생성 및 운영해주니 쓰레드의 안정성에 대해서 걱정하지 않아도 됩니다.
  • 선언적인 보안 관리
  • 서블릿 컨테이너를 사용하면 개발자는 보안에 관련된 내용을 서블릿 또는 자바 클래스에 구현해 놓지 않아도 됩니다. 일반적으로 보안관리는 XML 배포 서술자에다가 기록하므로, 보안에 대해 수정할 일이 생겨도 자바 소스 코드를 수정하여 다시 컴파일 하지 않아도 보안관리가 가능합니다.

4-3. Servlet 생명주기

순서

1. 클라이언트의 요청이 들어오면 Container는 해당 서블릿이 메모리에 있는지 확인하고, 없을 경우 init()메소드를 호출하여 적재한다. 이때 init()메소드는 처음 한번만 실행되기 때문에 공통적으로 사용해야하는 것이 있다면 오버라이딩하여 구현하면 된다.

2. init()이 호출된 후 클라이언트의 요청에 따라서 service()메소드를 통해 요청에 대한 응답이 doGet(), doPost()로 분기되는데, 이때 서블릿 컨테이너가 클라이언트 요청이 오면 가장 먼저 처리하는 과정으로 생성된 HttpServletRequest, HttpServletResponse에 의해 request와 response객체가 제공된다.

3. 컨테이너가 서블릿에 종료 요청을 하면 destroy()메소드가 호출되는데 마찬가지로 한번만 실행되며, 종료시에 처리해야하는 작업들은 destroy()메소드를 오버라이딩하여 구현하면 된다.

5. DispatcherServlet

앞서 본 Servlet Container에서 HTTP프로토콜을 통해 들어오는 모든 요청을 프레젠테이션 계층의 제일 앞에 둬서 중앙집중식으로 처리해주는 프론트 컨트롤러이다.

DispatcherServlet은 해당 애플리케이션으로 들어오는 모든 요청을 URL에 따라서 핸들링해준다.

순서

1. 클라이언트의 요청을 DispatcherServlet이 가로채서 HandlerMapping을 통해 해당 요청의 URL을 맞는 Controller를 찾는다.

2. 찾은 Controller에게 처리요청을 넘겨주면, Controller는 해당 요청에 따라 처리를 하고 결과를 출력할 View의 이름을 DispatcherServlet에게 리턴한다.

3. DispatcherServlet은 ViewResolver에 정의된 이름에 따라서 맞는 View를 찾아서 처리결과를 View에게 전달한다.

4. 처리결과가 포함된 View는 다시 DispatcherServlet을 통해서 클라이언트에게 출력되어진다.

6. JSP(Java Server Page)

java 코드가 들어가 있는 HTML코드이다.
서블릿은 자바코드 속에 HTML코드가 들어가는 형태인데, JSP는 이와 반대로 HTML소스코드속에 자바 소스코드가 들어가는 구조를 갖는 웹애플리케이션 기술이다.

보통 <% 소스코드 %> 또는 <%= 소스코드 %>의 형태로 들어가게 된다.

자바소스코드로 작성된 이부분은 웹 브라우저로 가지 않고, 웹 서버에서 실행되는 부분이며, 웹 프로그래머가 소스코드를 수정할 경우에도 디자인 부분을 제외하고 자바 소스코드만 수정할 수 있기 때문에 효울적이다.

서블릿 규칙은 꽤나 복잡하기 때문에 JSP가 나오게 되었는데 JSP는 WAS에 의하여 서블릿 클래스로 변환하여 사용되어 진다.

순서

1. 웹 서버가 사용자로부터 서블릿에 대한 요청을 받으면 서블릿 컨테이너에 그 요청을 넘긴다.

2. 요청을 받은 컨테이너는 HTTPRequest와 HTTPResponse객체를 만들어 요청에 따라 doGet()이나 doPost()메소드 중 하나를 호출한다.

3. 서블릿은 데이터의 입력,수정 등에 대한 제어를 JSP에게 넘겨서 프레젠테이션 로직을 수행한 후 컨테이너에게 Response를 전달한다. 이를 통해서 손쉽게 비즈니스 로직과 프레젠테이션 로직을 분리하여 개발할 수 있다.

7. MVC 패턴 구조

Model, Controller, View의 약자로써 MVC는 사용자와 상호작용하는 소프트웨어를 디자인함에 있어 3가지 요소로 쪼개어 하는 것을 가르킨다.

7-1. MVC 구조 구성 요소

  • Model
    프로그램 내부 상태, 즉 프로그램의 정보(데이터)를 말하는 것
  • Controller
    데이터와 비즈니스 로직 간의 상호 작용을 뜻한다.
  • View
    사용자 인터페이스 요소를 뜻하는데, 유저에게 보여지는 것을 말한다.

7-2. MVC1 구조, MVC2 구조, Spring MVC 구성요소

MVC1구조

MVC1구조는 JSP가 View와 Controller의 역할을 모두 한꺼번에 하는 것이다. 이 뜻은 즉, 비즈니스 로직을 처리하기 위한 코드와 웹 브라우저에 결과를 출력하기 위한 출력 관리 코드가 섞여 있는 구조이다.

JSP페이지 안에서 모든 정보를 표현, 저장, 처리하므로 재사용이 힘들고, 가독성이 떨어진다.

  • 정의 : 모든 클라이언트의 요청과 응답을 JSP가 담당하는 구조이다.
  • 장점 : 단순한 페이지 작성으로 쉽게 구현 가능하다. 중소형 프로젝트에 적합!
  • 단점 : 웹 애플리케이션이 복잡해질수록 유지보수 문제가 발생한다.

MVC2구조

MVC1과 다르게 웹 브라우저의 요청을 하나의 서블릿이 받게 된다.
서블릿은 해당 요청을 비즈니스 로직에 따라 처리하고 그 결과를 JSP페이지로 포워딩한다.

*포워딩이란? 해당 도메인을 입력했을 경우에 지정된 사이트로 자동적으로 연결되도록 조작해놓은 경우를 말한다.즉, 다른 도메인으로 보내는 것이다. 보통 호스트를 설정할 수 없을 때 사용한다.
EX.홍길동
CF.호스트 설정: 도메인과 IP를 연결시키는 것을 의미

  • 정의 : 클라이언트의 요청처리, 응답처리, 비즈니스 로직을 각각 모듈화한 구조이다.
  • 장점 : 처리 작업의 분리로 인해 유지보수와 확장이 쉽다.
  • 단점 : 구조 설계를 위한 시간이 많이 소요되므로 개발 기간이 증가한다.

Spring MVC 구성요소

  • DispatcherServlet
  • 클라이언트의 요청을 전달받아 요청에 맞는 컨트롤러가 리턴한 결과값을 View에 전달하여 알맞은 응답을 생성
  • HandlerMapping
  • 클라이언트의 요청 URL을 어떤 컨트롤러가 처리할지 결정
  • Controller
  • 클라이언트의 요청을 비즈니스 로직에 맞게 수행한 후, 결과를 DispatcherServlet에게 리턴
  • ViewResolver
  • 컨트롤러의 처리 결과를 생성할 뷰를 결정
  • View
  • 컨트롤러의 처리 결과 화면을 생성, JSP 또는 Velocity 템플릿 파일 등을 뷰로 사용

8. Annotation

@을 이용한 주석, 자바코드에 주석을 달아 특별한 의미를 부여하는 것을 말한다.

클래스, 메소드, 변수 단위로 모든 요소에 선언이 가능하다. 프로그램 코드의 일부가 아닌 프로그램에 관한 데이터를 제공하고, 코드에 정보를 추가하는 정형화된 방법이다.

  • @Autowired
    • 의존성을 주입하여 자동으로 객체를 생성해주며 메소드 위에 사용할 경우 기본 생성자를 만들어준다.
    • @Autowired는 타입에 따라 매핑되기 때문에 동일 인터페이스를 상속받을 경우 구분의 모호함이 발생할 수 있음
    • 의존관계를 자동설정할 때 사용하며 타입을 이용하여 의존하는 객체를 삽입해 준다. 그러므로 해당 타입의 bean 객체가 존재하지 않거나 또는 2개 이상 존재할 경우 스프링은 예외를 발생시킨다.
  • @Qualifier
    • Type에 따라 매칭되는 @Autowired의 불편함을 줄여주기위해 상기 Annotation을 활용하여 특정 bean을 가리켜준다.
    • @Autowired 아래 @Quailfier("빈형식") 형식으로 사용한다.
  • @Resource
    • Autowired와 Quailfier를 합친 형태이다.
    • @Resource(name = "bean이름") 형식으로 사용한다.
  • @Component-scan
    • xml을 좀 더 가볍게 하기위해 활용하며 xml에 component-scan을 추가한다.
    • context:component-scan base-package = "의존성을 주입할 경로"와 같은 형태로 쓰인다.
  • @Component
    • Annotation을 Autowired할 클래스위에 표시해준다.
  • @PostConstruct
    • 상기 Annotation을 활용하여 간단히 초기화 작업을 수행한다.
  • @Aspect
    • 공통적인 부분을 가지는 클래스 위에 써서 공통 Bean을 만든다.
  • @pointcut
    • aspect bean 객체 내에 있는 공통의 메소드를 언제 실행할 것인가에 대한 조건이다.
  • @around
    • pointcut에 들어가는 Advice를 감싸는 부분이다.
  • @RequestMapping
    • 특정 URI에 매칭되는 클래스나 메소드임을 명시해준다.
  • @Controller
    • 스프링 MVC 컨트롤러 객체임을 명시한다.
  • @RequestParam
    • 요청에서 특정한 파라미터의 값을 찾아낼 때 사용
  • @Repository
    • @Component의 하위 계층이며, DAO(Data Access Object)객체임을 명시한다.
  • @Service
    • @Component의 하위 계층이며, Service객체임을 명시한다.
  • @ModelAttribute
    • 자동으로 해당 객체를 뷰까지 전달한다.
  • @PathVariable
    • 현재의 URI에서 원하는 정보를 추출
  • @SessionAttribute
    • 세션상에서 모델의 정보를 유지하고 싶은 경우에 사용

 

출처 : https://velog.io/@wldus9503/Spring-스프링-특징