스프링 프레임워크에 대해

 

1. 스프링 프레임워크의 차별성

 

1-0) 스프링은 경량 프레임워크다.

 

스프링은 가장 성공적인 '경량(light-weight) 프레임워크' 이다.

 

 

 

스프링은 특정 기능을 위주로 간단한 jar 파일 등을 이용해서 모든 개발이 가능하도록 구성된 

 

프레임워크이다.

 

1-1) 복잡함에 반기를 들어서 만들어진 프레임워크

 

엔터프라이즈급 프레임워크들의 가장 큰 문제점으로는 복잡성으로 보고 있다.

 

다양한 경우를 처리할 수 있는 다양한 기능을 가지도록 만들다 보니 하나의 기능을 위해서 너

 

무 많은 구조가 필요한상태가 되었다. 이러한복잡성을 해결하기 위해서 나온 경량화된 프레임

 

워크가 스프링이다. 일반적인 Java의 클래스와 인터페이스를 이용하는 구조이기 때문에 진입

 

장벽이 높지 않았고，EJB(Enterprise JavaBeans)로 대표되는 복잡한 프레임워크에 비해 가볍

 

기 때문에 빠르게 엔터프라이즈급의 시스템을 작성할 수 있다.

 

 

1-2) 프로젝트의 전체 구조를 설계할 때 유용한 프레임워크

 

다른 프레임워크들은 웹 영역이나 데이터베이스 영역 등의 전문적인 영역에 대해서만 지원하

 

는 경우가 많았고, 비즈니스 로직을 처리하는 부분에 대한 설계는 개발자의 역량에 맡기는 경

 

우가 많았다. 반면에 스프링은 어느 한 분야에 집중하지 않고, 전체를 설계하는 용도로 사

 

용될 수 있었다. 사실 스프링 프로젝트가 대부분이 Web이라는 제한된 영역에서 많이 사

 

용되기는 하지만，근본적인 사상 자체는 OOP 구조를 뒷받침하고 구조를 설계하는 사상이다

 

1-3) 다른프레임워크들의 포용

 

스프링은 전체 구조에 집중했기 때문에 특정한 영역의 프레임워크와 공존하는 방식으로 사용

 

할 수 있었다. 다른 프레임워크들은 특정 프레임워크를 채택하면 해당 영역 전체를 수정

 

해야 하는 고질적인 문제를 가지고 있었지만, 스프링은 다른 프레임워크들과의 통합을 지원

 

했기 때문에 최소한의 수정이 가능했다. 스프링의 최대 장점은 기본 뼈대를 흔들지 않고，

 

여러 종류의 프레임워크를 혼용해서 사용할 수 있다는 점이다.

 

ibatis, hibernate, struts, JPA, JDO, JMS, Quertz 등 다른 프레임워크 뿐 아니라 사용자가 만든 
프레임워크와의 연동성

을 제공한다.

 

1-4) 개발 생산성과 개발도구의 지원

 

스프링의 경우 이론적으로는 개발자가 제대로 이해해야 하는 부분이 많았지만, 결과적으로 

 

코드의 양은 확실히 줄어들 수 있었고, 유지 보수에 있어서도 XML의 설정 등을 이용했기 때문

 

에 환영받을 수 있었다. STS나 Eclipse, Intellij 등의 플러그인의 지원 역시 다른 프레임워크들

 

에 비해서 빠른 업데이트가 되었기 때문에 별도의 새로운 개발도구에 대한 적응이 없

 

이도 개발이 가능했다.

 

1-5) 스프링의 변화들

 

• Spring 2.5버전: 어노테이션(Annotation)을 활용하는 설정을 도입하면서 편리한 설정과 개발이 가능하도록 지원

• Spring 3.0버전: 별도의 설정 없이도 Java 클래스만으로 설정 파일을 대신할 수 있게 지원

• Spring 4.0버전: 모바일 환경과 웹 환경에서 많이 사용되는 REST 방식의 컨트롤러 지원

• Spring 5.0버전: Reactor를 이용한 Reactive 스타일의 개발 환경 지원

 

2. 스프링의 주요 특징

 

• POJO 기반의구성

• 의존성주입(DI)을 통한 객체간의 관계 구성 - 스프링의 핵심 기능

• Ioc(Inversion of Control)

• AOP(Aspect-Oriented-Programming) 지원 - 스프링의 핵심 기능

• 편리한 MVC 구조

• WAS의 종속적이지 않은 개발 환경

 

3-1) POJO 기반의 구성

 

스프링의 성격 자체가 가벼운(light-weight)프레임워크지만, 그 내부에는 객체 간의 관

 

계를 구성할 수 있는 특징을 가지고 있다. 스프링은 다른 프레임워크들과 달리 이 관

 

계를 구성할 때 별도의 API등을 사용하지 않는 POJO(Plain Old Java Object)의 구성

 

만으로 가능하도록 제작되어 있다. POJO는 직역하면 평범한 옛날 자바 객체이다. 

 

말 그대로 자바 객체를 뜻한다. 일반적인 Java 코드를 이용해서 객체를 구성하는 방식을 그대

 

로 스프링에서 사용할 수 있다는 얘기다.

 

과거에는 자바로 웹 애플리케이션을 설계하기 위해 Servlet 클래스를 상속받아 구현하였다.

 

Servlet 클래스를 이용해서 구축하려면 반드시 Servlet 에서 요구하는 규칙에 맞게 클래스를 만

 

들어야 실행할 수 있다. 또한 이 Servlet 클래스를 이용하여 비즈니스 로직 외의 것들을 구축하

 

는데 많은 시간이 소요되었다. 즉, 이  Servlet 클래스는 POJO가 아닌것이다. 개발자가 직

 

접 Servlet클래스를 작성하지 않고, POJO 만으로(일반적인 자바 객체로) 웹 애플리케이션을 

 

구축할 수 있으며 비즈니스 로직에 집중할수 있는것이 스프링의 특징이다. 그리고

 

이것이 중요한 이유는 코드를 개발할 때 개발자가 특정한 라이브러리나 컨테이너의 기술

 

에 종속적이지 않다는 것을 의미하기 때문이다. 개발자는 가장 일반적인 형태로 코드를

 

작성하고 실행할 수 있기 때문에 생산성에서도 유리하고, 코드에 대한 테스트 작업 역시

 

좀 더 유연하게 할 수 있다는 장점이 생긴다.

 

3-2) 의존성 주입(DI)을 통한 객체간의 관계 구성

 

( 기존에 정리해둔것 : https://cg-developer.tistory.com/313 ) 

 

의존성(Dependency)이라는 것은 하나의 객체가 다른 객체 없이 제대로 된 역할을 할 수

 

없다는 것을 의미한다. 

 

이처럼 하나의 객체가 다른 객체의 상태에 따라 영향을 받는 것을 의미한다.

 

흔히 A 객체가 B 객체 없이 동작이 불가능한 상황을 ’A가 B에 의존적이다’라고 한다.

 

 

주입(Injection)은 말 그대로 외부에서 밀어 넣는 것을 의미한다.

 

의존성과 주입을 결합해서 생각해 보면 '어떤 객체가 필요한 객체를 외부에서 밀어 넣는

 

다’는 의미가 된다. 

 

그렇다면  왜 외부에서 객체를 주입하는 방식을 사용할까?

 

주입을 받는 입장에서는 어떤 객체인지 신경 쓸 필요가 없다

 

어떤 객체에 의존하든 자신의 역할은 변하지 않기때문이다.

 

의존성 주입방식을 사용하려면 오른쪽 그림의 바깥쪽 도형처럼 추가적인 하나의 존재가

 

필요하게 된다. 이 존재는 의존성이 필요한 객체에 필요한 객체를 찾아서 주입하는 역

 

할을 하게 된다.

 

 

스프링은 이러한 구조를 만드는 데 적합한 구조로 설계되어 있다. 

 

스프링에서는 ApplicationContext 라는 존재가 필요한 객체들을 생성하고, 필요한 객체들을 

 

주입하는 역할을 해주는 구조이다. 따라서 스프링을 이용하면 개발자들은 기존의 프로그래

 

밍과 달리 객체와 객체를 분리해서 생성하고, 이러한 객체들을 엮는(wiring) 작업을 하는 형태

 

의 개발을 하게 된다. 스프링에서는 ApplicationContext가 관리하는 객체들을 빈

 

(Bean)이라는 용어로 부르고, 빈과 빈 사이의 의존관계를 처리하는 방식으로 

 

XML 설정, 어노테이션 설정, Java 설정 방식을 이용할 수 있다.

 

 

의존성 주입 테스트

 

예제로 구성할 내용은 레스토랑(Restaurant) 객체를 만들고 레스토랑에서 일하는

 

셰프(Chef) 객체를 주입하는 예제를 작성하려고 한다

 

스프링에서는 생성자를 이용한 주입과 setter 메서드를 이용한 주입으로 의존성 주입을

 

구현한다. 

 

주입방식 정리 : https://cg-developer.tistory.com/382

 

 

 

package org.zerock.sample;
    import org.springframework.beans.factory.annotation.Autowired;
    import org.springframework.stereotype.Component;
    import lombok.Data;
    import lombok.Setter;
    
@Component //@Component는 스프링에게 해당 클래스가 스프링에서 관리해야 하는 대상임을 표시하는 어노테이션 그러면 스프링은 이클래스 인스턴스를 생성해줌
@Data //@Data는 setter를 생성하는 기능과 생성자，toString() 등을 자동으로 생성
      // @ToString, @EqualsAndHashCode, @Getter/©Setter, 
      //@RequiredArgsCtonstructor를 모두결합한 형태로 자주 사용되는 모든 메서드들을 한 번에 생성할 수 있다는 장점
public class Restaurant {//Restaurant 객체는 Chef 타입의 객체를 필요로 하는 상황
     
 @Setter(onMethod_ = @Autowired)
     private Chef chef;
     /*
         @setter는 자동으로 setChef()메서드를 컴파일 시 생성함
         @Setter에서 사용된 onMethod 속성은 생성되는 setChef()메소드에 @Autowired 어노테이션을 추가하도록함
         스프링은 @Autowired 어노테이션붙어서 chef객체를 주입해줌
     */
} 

 

스프링은 클래스에서 객체를 생성하고 객체들의 의존성에 대한 처리 작업까지 내부에서

 

모든 것이 처리된다. 스프링에서 관리되는 객체를 흔히 ’빈(Bean)’이라고 하고，이에 대

 

한 설정은 XML과 Java를 이용해서 처리할 수 있다

 

root-context.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"
    xmlns:context="http://www.springframework.org/schema/context"
    xsi:schemaLocation="http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.3.xsd">
    
    <!-- Root Context: defines shared resources visible to all other web components -->
    <context:component-scan base-package="org.zerock.sample"></context:component-scan>
<!--     ©Component는 해당 클래스가 스프링에서 객체로 만들어서 관리하는 대상임을 명시하
는 어노테이션, ©Component가 있는 클래스를 스프링이 읽어 주도록 ComponentScan을 통해서 해당 패키지에 있는 클래스들
을 조사하면서 @Component가 존재하는 클래스들을 객체로 생성해서 빈으로관리 -->
</beans>

 

Bean Graph' 랩을 선택해 보면 Restaurant와 Chef 객체가

설정된 것을 확인할 수 있다.

 

 

스프링과 context 그리고 클래스들의 동작순서

 

 

 

작성한 2개의 클래스와 root—context.xml이 어떻게 동작하는지 이해하기 위해서는 스

 

프링과 함께 시간의 순서대로 봐보자

 

스프링 프레임워크가 시작되면 먼저 스프링이 사용하는 메모리 영역을 만들게 되는데 이를 컨텍스

 

트(Context)라고 한다. 스프링에서는 ApplicationContext라는 이름의 객체가 만들어진다.

 

• 스프링은 자신이 객체를 생성하고 관리해야 하는 객체들에 대한 설정이 필요하다.

 

이에 대한 설정이 root-context.xml 파일이다.

 

root-context.xml에 설정되어 있는(context:component-scan) 태그의 내용을 통해서 

 

org.zerock.sample 패키지를 스캔(scan)하기 시작한다.

 

• 해당 패키지에 있는 클래스들 중에서 스프링이 사용하는(Component라는 어노테이션이 존재하

 

는 클래스의 인스턴스를 생성한다.

 

• Restaurant 객체는 Chef 객체가 필요하다는 어노테이션(@Autowired) 설정이 있으므로, 스프링은

 

Chef 객체의 레퍼런스를 Restaurant 객체에 주입한다.

 

 

3-3) 제어 역행 : Ioc(Inversion of Control)

 

 

스프링에서는 또 다른 특징으로 IoC(Inversion of Control)을 말할 수 있다. 

 

IoC는 제어의 역전이라고 말하며, 간단히 말해 제어의 흐름을 바꾼다라고 한다.

 

기존에는 다음과 순서로 객체가 만들어지고 실행되어졌다.

 

1. 객체 생성

2. 의존성 객체 생성(클래스내부에서)

3. 의존성 객체 메소드 호출 

 

하지만, 스프링에서는 다음과 같은 순서로 객체가 만들어지고 실행된다.

 

1. 객체 생성

2. 의존성 객체 주입(스스로가 만드는것이 아니라 제어권을 스프링에게 위임하여 스프링이 만들어놓은 객체를 주입한다.)

3. 의존성 객체 메소드 호출

 

스프링이 모든 의존성 객체를 스프링이 실행될때 다 만들어주고 필요한곳에 주입시켜줌으로써 

 

Bean들은 싱글턴 패턴의 특징을 가지며, 제어의 흐름을 사용자가 컨트롤 하는 것이 아니라 스프링

 

에게 맡겨 작업을 처리하게 된다.

 

3-4) 관점 지향 프로그래밍 AOP(Aspect Oriented Programming)의 지원

 

여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있다.

 

좋은 개발환경의 중요 원칙은 개발자가 비즈니스 로직에만 집중할 수 있게 한다이다.

 

이 목표를 이루기 위해서는 몇 가지 중요한 원칙이 있지만, 가장 쉽게 생각할 수 있는 것이

 

반복적인 코드의 제거라고 할 수 있다. 스프링은 프레임워크를 이용한 개발에도 이러

 

한 반복적인 코드를 줄이고, 핵심 비즈니스 로직에만 집중할 수 있는 방법을 제공한다.

 

대부분의 시스템이 공통으로 가지고 있는 보안이나 로그, 트랜잭션과 같이 비즈니스 로직

 

은 아니지만, 반드시 처리가 필요한 부분을 스프링에서는 ’횡단 관심사(cross-concern)’

 

라고 한다. 스프링은 이러한 횡단 관심사를 분리해서 제작하는 것이 가능하다.

 

AOP(Aspect Oriented Programming)는 이러한 횡단 관심사를 모듈로 분리하

 

는 프로그래밍의 패러다임입니다.

 

스프링은 AOP를 Aspectj의 문법을 통해서 작성할 수 있는데，

 

이를 통해서 개발자는 

 

1) 핵심 비즈니스 로직에만 집중해서 코드를 개발할 수 있게 되었고

 

2) 각 프로젝트마다 다른 관심사를 적용할 때 코드의 수정을 최소화시킬 수 있었으며

 

3) 원하는 관심사의 유지보수가 수월한 코드를 구성할 수 있다.

 

3-5) 트랜잭션의 지원

 

데이터베이스를 이용할 때 반드시 신경 써야 하는 부분은 하나의 업무가 여러 작업으로

 

이루어지는 경우의 트랜잭션 처리이다. 이 트랜잭션 처리는 상황에 따라서 복잡하게 구

 

성될 수도 있고，아닐 수도 있는데，그때마다 코드를 이용해서 처리하는 작업은 개발자에

 

게는 상당히 피곤한 일이다. 스프링은 이런 트랜잭션의 관리를 어노테이션이나 XML로

 

설정할 수 있기 때문에 개발자가 매번 상황에 맞는 코드를 작성할 필요가 없도록 설계되

 

었다.