[개념쌓기]Spring, 왜 쓰는걸까?

그 많은 것들 중에 왜 스프링일까

자바 강국 한국, 종종 다들 너무 당연하게 여겨서 의문조차 품지 않는다.

나조차도 여지껏 사용하다가  왜 쓰는 지를 이제야 자신에게 되묻는다.

 

- 기존 쓰던 프레임워크를 두고 다른 프레임워크를 사용하기엔 부담이 크다
- 그동안 쌓인 래퍼런스가 많다 등이 있을 것이다.

라는 내 생각보단 대표적인 이유는 "전자정부 표준프레임워크"이기 때문인 듯하다.

 

진짜 잠깐만 짚고 넘어가자.

  프레임워크(Framework)란 무엇일까?

단어 그대로 뼈대나 근간을 이루는 코드들의 묶음이다.

즉, 소프트웨어의 구체적인 부분에 해당하는 설계,구현을 재사용이 가능하게해 일련의 협업화된 형태로 클래스들을 제공하는 것이다.

 

요약하면 기본 흐름이나 구조를 정하는 것이 프레임워크다.

 

 

  1. POJO기반 구성 (Plain Old Java Object)

코드 개발 시, 개발자가 특정 라이브러리나 컨테이너의 기술에 종속적이지 않음을 의미.

Java코드를 이용해 객체 구성 방식 그대로를 스프링에서 사용 가능하다.

 

덕분에, 자유롭게 객체지향적인 설계 구현이 가능하다.

개발자는 일반적인 형태로 코드를 작성해 실행 가능하기 때문에 높은 생산성과 유연한 테스트를 할 수 있는 장점을 가지게 된다.

 

 

  2. DI(Dependency Injection,의존성 주입)을 통한 객체 관계 구성

 

"DI는 객체지향 프로그래밍의 강력한 지원군이다."

 

 

의존성 주입은 제어의 역전이 일어나는 것을 전제로 스프링 내부의 객체들 간의 관계를 관리할 때 사용.

의존성 주입은 특정 개체에 필요한 객체를 외부에서 결정해 연결시키는 것을 말한다

자바에서는 인터페이스를 사용해 의존적인 관계를 처리

 

- 메소드나 객체(bean)의 호출 작업은 제어의 역전을 통해 외부에서 이뤄짐(외부라 함은 객체를 기준으로 외부를 의미)

- 제어의 역행을 전제로 의존성 주입이 일어남

- 의존성을 가진 객체는 스프링에서 의존성 주입을 발생시킨다

 

실무에서는 주로 정형화된 컨트롤러,서비스,레포지토리 같은 코드는 컨포넌트 스캔을 사용.

정형화되지 않거나, 상황에 따라 구현 클래스를 변경하여 설정으로 스프링 빈으로 등록.

 

 

컴포넌트 스캔과 자동 의존관계 설정

 

예를 들어, ArticleController의 생정자에 @Autowired를 붙여, 스프링이 저장한 ArticleService객체를 컨트롤러가 생성될 때 가져와 준다. 즉, 생성자에 @Autowired가 있으면 스프링이 연관된 객체를 스프링 컨테이너에서 찾아 넣어준다. 이렇게 객체 의존관계를 외부에서 넣는 것을 의존성 주입(DI)라고 한다.

 

의존성 주입 방법

1. 필드 주입

2. setter 주입

3. 생성자 주입 (권장)

 

생성자 주입 권장 이유

1.  순환 의존성 확인 : 필드 주입으로는 순환 의존성 파악이 어려움. 생성자 주입 시에 서버 기동 시 순환 의존성을 가지는 요소들을 파악하며 에러메시지를 표시해준다

2. 불변성 : 필드 주입은 final을 선언할 수 없으나 생성자 주입은 final을 통해 객체가 변하지 않게 방지함

3. 단일 책임 원칙 위반 

 

  @Autowired 어노테이션을 이용한 의존성 주입

객체 연결 시에 사용.필드 혹은 생성자에 사용하여 컨트롤러,서비스 생성 시 스프링빈에 등록한 객체를 갖다 넣어줌

 

1. 필드 주입 방법

public class ExampleCase{

	@Autowired
    private ChocolateService chocolateService;
    
    @Autowired
    private DrinkService drinkService;
}

 

2. 생성자 주입 방법 (권장)!!!!!!!!!!!!!!!!

public class ExampleCase{
	private final ChocolateService chocolateService;
    private final DrinkService drinkService;
    
    @Autowired
    public ExampleCase(ChocolateService chocoalteService, DrinkService drinkService){
    	this.chocolateService = chocolateService;
        this.drinkService = drinkService;
   }
}

 

  @RequiredArgsConstructor 어노테이션을 이용한 의존성 주입

 

@RequiredArgsConstructor // final로 선언된 멤버 변수를 자동 생성
@RestController //JSON 형태로 데이터 주고 받음
public class ProductRestController{
          
         private final ProductService producctService;
         private final ProductRepository productRepository;
         
         //등록된 전체 상품 목록 조회
         @GetMapping("/api/products")
         public List<Product> getProducts(){
         	return productRepository.findId();
           }
}

@RequiredArgsConstructor라는 어노테이션을 붙이면 final 필드나 @NonNull이 붙은 필드에 대해 생성자를 생성해 준다. 주로 의존성 주입의 편의성을 위해 사용된다.

 

어떤 빈(Bean)에 생성자가 오직 하나만 있고, 생성자의 파라미터 타입이 빈으로 등록 가능한 존재라면 이 빈은 @Autowired 어노테이션 없이도 의존성 주입이 가능하다.

 

 

  3. AOP(관점지향 프로그래밍) 지원

관심사를 깔끔하게 분리하여 처리해줌

 

먼저 짧게 얘기해보자.

나무위키에서는

"전공자들을 위해서 더 쉽게 설명하자면 C언어에서는 중복할당을 줄이기 위해서 간접적으로 값을 가리키는 포인터로 가리키는데, Spring에서는 반복할당을 줄이기 위해 포인터를 대신하여 스프링 어노테이션을 사용하는 것이라고 보면 된다"

라고 한다. 이 말을 보고 바로 이해가 된다면 아하! 하고 넘어가면 되지만, 그게 아니라면 AOP에 대해 좀 더 공부하자.

 

매우 똑디한 개발자분이 정리를 아주 잘해주셔서 그대로 공수해왔다. 링크는 물론 아래에 남겼다퍼가기가 안돼서 한 번 더 커스텀해서 타이핑했다 ㅠㅠㅠㅠㅠㅠㅠ.원문을 쓰신 분의 필력이 더 좋기에 원문을 참고해도 좋다~ https://joychae.tistory.com/27 해당 링크를 통해 참고하자

 

" 공통 관심 사항(cross-cutting concern) vs 핵심 관심 사항(core concern)"

비즈니스 로직은 아니지만 보안, 로그, 트랜잭션과 같이 반드시 처리가 필요한 부분을 스프링에서는 공통 관심사항이라 한다. 예를 들어, 회원가입과 회원 조회에서 시간을 측정하는 기능은 핵심 관심 사항이 아니다. 여기서 시간을 측정하는 기능은 공통 관심 사항이다. 이들을 같은 Class 안에 메소드로 구현하면 핵심 비즈니스 로직과 공통 관심 사항에 해당하는 로직이 섞여서 유지보수가 매우 어렵다. 하지만 시간을 측정하는 로직은 별도의 공통 로직으로 만들기도 매우 어렵다. 이 경우 시간을 측정하는 로직을 변경 시 모든 로직을 찾으며 변경하는 불상사가 발생한다

위 그림과 같이 모든 Class에 시간 측정 로직을 따로 작성해, AOP를 사용해 아래의 그림처럼 한 번에 해결가능하다.

 

 

@AOP로 활용할 객체에는 @Aspect 어노테이션을 붙여줘야 한다.

@Around로 AOP를 적용할 객체를 지정한다. 문법을 익히면 반복 패턴이라 단순하다.

레퍼런스에는 있었지만,내가 이해를 못해서 따로 정리해서 올리려고 한다.

 

 

  4. 편리한 MVC 구조

MVC = Model, View, Controller

 

 - Model

       :  어플리케이션의 데이터, 모든 데이터 정보를 가공해 가진 컴포턴트

       : 사용자가 이용하려는 모든 데이터를 가져야함

       :  View 또는 Controller의 정보가 없어야한다(Model을 통해 제공되는 정보가 없어야함)

 

- View

       : 시각적인 UI 요소를 지칭하는 용어

       : Model이 가진 데이터를 저장하면 안됨

       : Model이나 Controller에 대한 정보를 알면 안되며, 단순 표시 역할만 가져가야함

 

- Controller

       : Model과 View를 연결해주는 역할

       : Model과 View에 대한 정보를 알아야함

       : Model, View의 변경을 인지해 대처가능해야함

 

  그렇다면 스프링의 단점은 무엇일까?

위에 말한 장점들을 거꾸로 보면 된다.

 

•   기능이 너무 많아서 무겁다
•   많은 기능을 제공하기 때문에, 기능 습득을 위한 상당한 노력과 시간이 필요하다

 

다른 장점들이 더 있지만,아직 공부하지 못한 내용들이기 때문에 공부를 통해 추가적으로 업로드할 계획이다.

Apache Tomcat/트랜잭션 등의 많은 장점이 있다.

 

지적해주시면 감사합니다.

 

참고자료 : 

https://ksbsite.tistory.com/3 

https://joychae.tistory.com/27 

https://nancording.tistory.com/84 

https://kimvampa.tistory.com/35 

https://freestrokes.tistory.com/79 

https://iri-kang.tistory.com/4