[Spring] 스프링 Core Technologies (IoC, DI, Bean, AOP, Validation, Data Binding, SpEL, Null Safety) 간단 정리

 

목차
1. 자바, 스프링, 스프링부트의 차이
2. IoC
3. Dependency Injection
4. Bean
5. AOP
6. Vaildation
7. Data Binding
8. Spring Resource
9. Spring Expression Language (SpEL)
10. Null Safety

 

---

1. 자바, 스프링, 스프링부트의 차이

1-1 자바

       한글과 같은 기본적인 언어이다.

 

1-2 스프링

       한글을 이용해서 책을 쓰는 템플릿, 어플리케이션

       각 목차, 챕터, 색인 등의 구성(틀)

       스프링이라는 틀 안에 자바, 코틀린, 그루비 등으로 작성 가능

        (+스프링 코드 품질 최상위. 심심할 때 스프링 코드 보기.)

 

 

태초에 자바가 있었고

웹이 활성화되면서 사용작의 액션에 따라 서버에서 응답을 줘야 하는 게 많이 필요해졌다.

이로 인해 자바를 이용해 서블릿(J2E)을 사용했다.

서블릿(다루기 힘듦)을 극복하기 위해 스프링이 탄생(자바의 겨울을 깨 주자!라는 어원..?)

 

라이브러리 : 특정한 상황에 맞춰 활용되는 기능

 

스프링(프레임워크) : 하나의 어플리케이션을 담아내는 큰 영역(그릇).

프레임워크에 라이브러리를 담고 있다.

DB에 접근, 메시징에 접근, 웹 기반 라이브러리 등 존재.

자바 프로그래밍을 더 빠르게, 쉽게 그리고 안전하게 해준다.

엔터프라이즈급 서비스를 개발하는데 유용하다.

비슷비슷한 기능들이 많기 때문에 어떤 걸 써야 하는지가 중요한 덕목이 됨.

 

1-3 스프링부트: 스프링의 상위 프레임워크

           스프링보다 한층 더 편리한 프레임워크

           우리가 필요한 부분만 어플리케이션만 개발할 수 있도록 환경 제공

           자동 설정, 설정 표준화 등 템플릿을 제공해준다.(로컬 설정에 대한 편리함 떡상!)

           +) 스프링부트는 Stand-Alone으로, Production-Level

          (제품으로 내보낼 수 있는 수준)의 스프링베이스 어플리케이션을 바로 실행할 수 있게끔 제공해준다.

 

주요 기능

- Stand-alone 스프링 애플리케이션

- 임베디드 tomcat 내장 (War파일 배포 필요 없다.)

- 빌드 설정을 단순화해줄 기초 세팅과 의존성

- 스프링 및 서드파티 라이브러리의 자동 설정

- 제품 레벨로 사용할 수 있는 각종 기능들.

- XML 설정 필요 없다.

 

 

[요점]

-  스프링이 자바 애플리케이션과 작성할 코드들을 강력한 프레임워크로 제공해준다.

-  스프링부트가 그것을 더 줄여준다.

 

---

[추가]

스프링 동작 원리를 모르면,

문제가 생겼을 때, 원인을 파악하기가 어려워진다.

--> A 케이스와 다른 B를 개발 할 때 문제점이 많이 발생한다.

따라서 스프링 프레임워크 Core Technology 동작 원리를 배워야 한다!

 

AOP(관점 지향적 프로그래밍) --> 다양한 공통 기능을 왔다 갔다 할 수 있게

Validation, Data binding       -->  API 만들 때 요청 값을에 담아 주는 것.

Resource                          --> 파일, 외부 url에 접근할 때, 스프링 외부 api에 접근할 때 사용

Null-safety                        --> 자바 작업 중 null 어떻게 관리하는지. 잘 처리하도록!

 

디자인 철학은다양한 기능에서 발전하고 있다.

한 가지 기능이 여러 개가 있기에 뭐가 좋은 건지 잘 모를 때가 많다.

 

 

---

2. IoC (Inversion of Control)

제어 역전(반전) : 전통적인 제어 흐름에 비추어볼 때, 제어 흐름을 반대로 뒤집은 것 . – 위키피디아

 

public class ServerFacade
{
  public Object respondToRequest(Object pRequest)
  {
    if(businessLayer.validateRequest(pRequest))
    {
      DAO.getData(pRequest);
      return Aspect.convertData(pRequest);
     }
     
    return null;
  }
}

해당 코드(위키피디아 참고)가 일반적인 제어의 흐름이다. 

ServerFacade가 pRequest를 받아 조건문을 통해 검증한다.

검증 후 해당 데이터가 DAO에 저장 하는 과정을 모두 알고 있다.

 

즉, validation data, DAO get Data , Aspect 모두 결합 되어 있다.

이에 따라 위 validation, dao, aspect가 추후 바뀔 경우에 해당 ServerFacade가 영향을 받는다.

 

[정리]

개발자가 자신의 뜻대로 클래스 내의 메소드에 여러 라이브러리(DAO. Aspect 등)를 능동적으로 직접 사용한다.

다시말해서, 개발자가 코드의 흐름을 직접 제어한다. 

 

 

하지만 아래(두 번째) IoC 형태의 코드는 딱 보기에도 간략해진다.

public class ServerFacade
{
  public Object respondToRequest(Object pRequest, DAO dao)
  {
    return dao.getData(pRequest);
  }
}

위에서 dao.get.data 이외의 validation, aspect는 생략했다.

추가로 DAO도 parameter(입력 인자)로 받아 사용하기 때문에 DAO가 변화 되어도 변화 된 값을 받아서 사용하게 된다.

 

이를 통해 위와 아래 ServerFacade의 차이점으로  다른 data, logic이 바뀌어도

해당 IoC형태의 코드에서는 getData 규약(인터페이스)만 잘 지켜준다면 해당 로직을 처리할 수 있게 된다.

 

위 ServerFacade에서 검증 로직,  get Data를 주는 방식에 따라 영향을 받지만

아래 SErverFacade에서는 검증 로직과 get Data 방식이 달라져도 영향을 받지 않는다.

--> request를 받아서  response로 주는 일만 수행함으로 비즈니스 로직이 분리 되었다.

[기존] DAO를 직접 ServerFacade에서 하던 것에서 DAO를 바깥으로부터 주입받았다. 

다시 말해서, 해당 클래스(ServerFacade)외에서 제어흐름을 관리하며 해당 클래스는 실행로직만 담당한다.

이는 스프링 프레임워크의 모듈이 개발자가 작성한 코드를 실행(외부에서 실행)하기 때문에 주도권이 프레임워크에 있기 때문이다. 

이를 제어 역전(Inversion of Control, IoC)이라고 부른다.

 

 

---

3. Dependency Injection

DI – Dependency Injection : 의존성 주입

 

시작 지점을 알고 싶다. (처음) --> 전체 구조가 어떻게 되어있길래 이해가 어렵다.

밑바닥부터 전체적으로 이해하기는 불가능하다.

핵심 원리를 이해하는 정도가 좋다.

 

뼈대가 있고, 해당 클래스를 넣어주기만 하면

해당 자바 클래스끼리 연결해준다. (레고판과 비슷하다. à 레고판 위에 올려놓는 클래스 : Bean)

판 밖에 있는 것들은 Class : 자바클래스

스프링은 큰 판을 의미(레고 판 : 장난감을 올려 연결, 상호작용하는 것)

 

---

 

4. Bean  

보통은 property와 method가 있고 메서드 프로퍼티를 이용해서 해당 클래스 행위를 하게 함

 

자바 Bean

특정 행위들이 없고 데이터를 저장하기 위한 용도의 구조체로 사용하는 것

Bean 규약 : private프로퍼티와 getter/setter로만 데이터 접근

 

스프링에서의 Bean

A, B, C 클래스를 만들고 등록하면, IOC컨테이너에 생성하고 관리되는 객체

스프링 IOC 컨테이너

빈으로 등록한다라는 의미는 단일 객체로 인스턴스화

등록한 객체를 스프링에서 설정 값(annotation)을 입혀준다.

각각의 Bean들끼리는 서로를 편리하게 의존(사용)할 수 있음.

과거에는 Bean 등록(package root 다 타이핑) 어려웠음

현재는 annotation 기반으로 Bean 등록한다.해당 어노테이션을 통해 스프링 안에서 어떠한 역할을 하는지 선언해줌. (옷을 입혀줌)

 

 

-정리-

스프링 IOC는 전체 Bean을 담고 있는 Container이다.

해당 컨테이너에는 Class를 설정을 입혀 인스턴스 화하여 Bean으로 만들어 담고 있다.

예전에는 xml로 담았지만, 현재는 annotation으로 쉽게 등록할 수 있다.

Bean을 생성할 때 singletone, prototype, request 등 생성 규칙 심을 수 있다.

Bean lifecycle callback을 통해 각 이벤트가 발생하는 경우 호출하는 메서드를 통해 빈의 사용 전/후로 추가 작업 가능하다.

 

---

 

5. AOP Aspect Oriented Programming : 관점 지향 프로그래밍

관점 지향 : 공통적인 부분을 스프링이 도와서 처리해준다.

특정 컨트롤러, 시점 등의 공통적인 부분에 사용

Ex)

- 특정 함수를 호출할 때만 로깅 (자세한 로깅)

- Transactional (스프링 MVC패턴에 많이 사용) 사용 시

  트랜젝션 어노테이션 붙일 때 AOP 기법을 써서 시작/끝 부분을 aop가 해줌.

- 인증, 추가적인 인증이 필요한 부분

- Lock을 사용해서 중복되면 안 될 때, 사용

 

실무에서는 적극적으로 사용하지 않고 보수적으로 꼭 필요한 부분에서 사용.
(코드 분석 어렵게 만든다.)

 

해당 함수 호출 전/후에 advice를 이용해서 각 이벤트(메서드) 실행하기.

결제 호출 시, 인증 먼저 실행 + 현재 시간 출력 , 결제 후 현재 시간 출력 등!

 

---

 

6. Validation

유효성 검증 : 사용자의 요청(http)을 받는 서버에서 요청 내용에서 잘못된 내용이 있는지 꼼꼼히 확인해 보는 단계

 

개발자가 주로 챙겨야 하는 검증은 크게 두 가지이다.

1) 데이터 검증

- 필수적인 데이터의 존재 유무

- 문자열의 길이

- 숫자 데이터 경우 값의 범위

- 이메일, 신용카드 번호 등 특정 형식에 맞춘 데이터

 

2) 비즈니스 검증

- 서비스 정책에 따라 데이터를 확인하여 검증.

- 예) 배달앱 경우, 배달 요청 주문건이 결제 완료 상태인지 / 결제 금액이 맞는지 등 확인.

-  경우에따라 외부 API 호출 혹은 DB의 데이터까지 조회하여 검증하는 경우

 

 

 

 

Spring의 Validation

스프링은 웹 레이어에 종속적이지 않은 방법으로 검증하려고 의도한다.(데이터 검증에 가까움)

 

1) Java Bean Validation

Java Bean : 쉽게 데이터를 저장할 수 있는 property와 Getter, Setter 등의 단순 구조 클래스

요즘 가장 많이 활용되는 방법 중 하나이며, JavaBean내에 어노테이션으로 검증방법을 명시한다.

 

 

Dto에 어노테이션으로 명시 후 @Valid 어노테이션을 해당 @RequestBody에 달게 되면,

Java Bean Validation을 수행한 후 문제가 없을 때만 메서드 내부로 진입된다.

--> 간단하고 validation 위치 찾기 쉬움.

 

2) Spring Validator 인터페이스 구현을 통한 validation

각 인스턴스에만 활용되는 validator

인터페이스에서 support, validate 메서드가 존재.

Support : 해당 validator가 동작할 조건을 정의하며, 주로 class의 타입을 비교한다.

Validate : 원하는 검증을 진행한다.

하지만, 이 방법은 validation을 수행하는 코드 찾기가 어렵다.
완전히 데이터만 검증하는 것이 아닌 비즈니스적인 검증이 들어가는 경우에 많이 사용된다. (복잡한 검증이 가능하기 때문.)

---

 

7. Data Binding

Validation 후 사용자, 외부서버의 요청 데이터(request)를 특정 도메인 객체에 저장해서 우리 프로그램에 Request에 담아주는 것을 의미한다.

 

Converter Interface

두 개의 타입을 가지는 인터페이스이다. source라는S타입을라는 S타입을 받아서 Target이라는 T 타입으로 리턴한다.
(리퀘스트에서 활용)

 

 

Ex) Json 형식 문자열이 담겨 오는 경우, 해당 문자열을 곧바로 특정 DTO(Java Bean)에 담고 싶을 때 사용.

 

동작 원리 : String을 전달받아 특정 Bean에 등록

외부 데이터 (Source class Type)가 들어오면, Converter에 등록된 형식과 일치하면 해당 Converter가 동작하고  Bean(Target Class Type)에 저장한다.

 

RequestBody가 Json형식의 데이터/키 벨류 값을 특정 객체로 바꿔주는 것이다.(컨버터 인터페이스)

 

Formatter

특정 객체와 String 간의 변환을 담당한다. (컨버터 인터페이스의 일종)

응답을 할 때도 활용하는 컨버터이며 리퀘스트와 리스폰스에 활용된다.

Formatter를 이용해 문자열을 Date(특정 객체)로 바꾸어 return 한다.

 

Converter와 마찬가지로 Spring Bean으로 등록하면, 자동으로 동작하여 요청/응답 시 해당 데이터 타입을 변환해주도록 동작한다.

---

8. Spring Resource

Java.net.url의 환계를 넘어서기 위해서 스프링에서 추가로 구현

 

Java.net.url은 외부 url접근 용도가 많고 이외에는 기능이 별로 없다.

스프링 내에서 스프링을 띄우기 위한 설정 값,  여러 클래스 파일을 접근할 때 한계 사항이 많았다.

이를 해결하기 위해 스프링 내부적으로 Resource, 파일들에 접근하기 위해 구현했다.

 

Resource 구현체 목록 : 스프링 내에서 특정 파일. 리소스 읽어오기 위한 구현체들

Spring 내부 Resource 구현체 중 대표적인 몇 가지

1) UrlResource
     --> 다양한 종류의 Resource(file, http)에 접근 가능 하지만, 기본적으로는 http로 원격 접근

2) ClassPathResource

     --> Classpath 하위의 리소스 접근 시 사용. (소스코드 빌드한 결과)

3) FileSystemResource

    --> File을 다루기 위한 리소스 구현체

4) SevletContextResource, InputstreamResource, ByteArrayResource 등..

 

Spring ResourceLoader

위의 구현체들을 실제 스프링에서 사용하는 방식.

스프링 프로젝트 내 Resource(파일 등)에 접근할 때 사용하는 기능이다.

해당 리소스들을 읽어오는, 로딩해주는 기능.

 

스프링 리소스 로더는 applicationcontext라는 곳에 붙어있다.

Applicationcontext는 스프링의 뇌 같은 기능.

스프링 리소스 로더를 사용하기 위해서는 applicationcontext를 불러서 이를 통해 file들 가져올 수 있다.

 

---

9. Spring Expression Language (SpEL)

표현 언어(Expression는 짧고 간단한 문법을 통해 필요한 데이터나 설정 값을 얻어올 수 있게 하는 특별한 형태의 표현식에 가까운 간편한 언어 (그래프 접근 등 가능 --> school.teacher.math.~~ )

 

 

주로 @Value(“$(config.value)”)와 같은 방식으로 설정 값 주입하는 데 사용.

실무에서는, Bean의 Property를 설정할 때 사용한다.

Bean의 Property를 특정 값으로 지정해놓지 않고 상황에 따라서 다른 값으로 받기 위할 때 사용.

 

 

[정리]

스프링 내에는 SpEL이 있고, 이는 평가식(Value( “ 어쩌구 저쩌구” ))을 통해서 결과에 맞는 Bean에 담도록 하며 프로퍼티 안에 있는 특정 키 값을 프로퍼티에 담아 줄 수 있다.

 

---

 

10. Null Safety

 

- Null 안정성 높이는 방법

- 보일러플레이트(똑같은 코드 반복해서 매번 쓰는 귀찮고 코드 품질 낮추는 거) 방지

- IDE에 경고 표시함으로써 1차적인 문제 방지하고 정확한 에러 위치 확인할 수 있도록.

 

사용 방안

9- 1) NonNull Annotation 사용

- 메서드 파라미터에 붙이는 경우 : null이라는 데이터가 들어오는 것을 사전에 방지

- 프로퍼티에 붙이는 경우 : null을 저장하는 경우 경고 메시지

- 메서드에 붙이는 경우, null을 리턴하는 경우 경고, 응답값을 저장하거나 활용하는 쪽도 NonNull이라고 신뢰하고 사용.

 

 

9- 2) Nullable Annotaion

 - @Nonnull과 반대로 해당 데이터가 null 될 수 있음을 명시함으로 리팩토리 시 도움이 됨.

자바에서 Null을 관리하기 위한 annotaion을 제공해주며 NonNulll, Nullable을 사용함으로 안전한 코딩을 할 수 있다.

 

 

---

 

해당 글은 '패스트캠퍼스 - 한 번에 끝내는 Spring 완.전.판 초격차 패키지 Online.' 강의를 수강하며 정리한 글입니다.

 

강의 내용을 이해하기 위해 정리한 것이므로 틀린 부분이 있을 수 있습니다.