[Spring] 왜 스프링을 쓰는가? (특징 & 계층 구조)

Spring을 왜 쓰는가에 대한 고찰... 

(개발자들의 생산성을 높이기 위해 굉장히 최적화하였다.)

 

Spring Framework

Java 기반의 플랫폼 개발을 위한 오픈소스 애플리케이션 프레임워크 중 하나.

※ 프레임워크
: 개발할 때 설계 기본이 되는 뼈대나 구조, 환경
(애플리케이션 흐름의 주도권을 가지고 있음)

 

 

재사용성, 확장성 부분에서 객체 지향 설계 원칙에 맞아 

개발을 쉽게 할 수 있도록 도와주고, 

개발자들이 핵심 로직을 효율적으로 개발할 수 있도록 

기본 틀, 공통 프로그래밍 모델과 API를 제공한다.

 

 

※ Core (DI, Ioc) : 스프링의 근간.

내가 만든 클래스를 스프링이 직접 관리하여 어플리케이션을 동작하게 한다.

스프링의 밑바탕 판.

 

 

 

---

 

Spring Framework 핵심 기술

1. 스프링 DI 컨테이너 (Spring DI Container)

- 컨테이너 : 스프링 컨테이너는 스프링에서 자바 객체(Bean)들을 관리하는 공간을 말한다.
자바 객체를 스프링에선 빈(Bean)이라고 하는데, 스프링 컨테이너에서는 이 빈의 
생성부터 솔멸까지를 개발자 대신 관리해주는 곳이라고 할 수 있다.


- IoC (Inversion of Control) : 제어권의 역전. 즉, 제어권이 스프링 프레임워크에 있다.
개발자가 제어권을 가지지 않음.
객체가 내부적으로 조작할 객체를 직접 생성하는 것이 아니라, 외부로부터 주입받는 것.
이때 객체를 외부로부터 주입해주는 작업을 DI라고 한다.


- DI (Dependency Injection) : 의존성 주입.
계층이나 서비스 간에 의존성이 존재할 경우, 스프링 프레임워크가 서로 연결해준다.

 

 

스프링 컨테이너는 애플리케이션을 개발자들이 쉽게 만들 수 있도록 

객체의 제어권을 스프링 프레임워크에 넘겨 컴포넌트의 의존관계 결정, 설정, 생명 주기를 해결해주는 것이다.

 

 

 

2. AOP (Aspect Oriented Programming)

관점 지향 프로그래밍.

공통적인 코드를 프레임워크 레벨에서 지원해주는 방법.

공통적으로 사용하는 코드들을 모아서
이 코드들이 필요한 특정 로직에 공통 기능을 적용할 수 있는 기술이다.

 

 

애플리케이션은 핵심기술(객체가 제공하는 고유의 기능)과 

부가적인 기능(단독적으로 사용되지 않고 핵심 기능을 보조하기 위한 기능)으로 구분할 수 있는데,

 

애플리케이션의 요구사항이 복잡해지고 어려운 기술들이 추가되면,

모든 책임과 관심사, 부가적인 기능들을 분리하는 게 어렵다.

 

 

스프링에서하는 AOP를 지원해, 개발자들이 다양한 서비스들과 기술들을 적용해도 

책임을 분리하여 클린 코드를 지향하는데 도와준다.

 

 

 

3. PSA (Portable Service Abstraction)

외부 라이브러리들을 POJO로 사용할 수 있도록 일종의 껍데기를 추상화한 것으로, 
스프링에서 추상화된 서비스들을 자바 언어로 자유롭게 사용 가능.

※ POJO (Plain Old Java Object)
: 특정 환경이나 규약에 종속되지 않고,
필요에 따라 재활용 될 수 있는 방식으로 설계된 자바 객체.

 

 

일관성 있는 서비스 추상화로, 

단순하게 다른 코드에서 어떠한 코드를 떼내어 다른 부분에 사용하여도 이상없도록 사용되는 경우를 볼 수 있다.

 

 

이처럼 특정 서비스를 이용할 때, 

서비스의 기능을 접근하는 방식 자체를 일관되게 유지하면서 

기술 자체를 유연하게 사용할 수 있는 것으로, 

개발자들이 기존 코드를 거의 변경하지 않고 웹 기술스택을 간편하게 바꿀 수 있도록 해준다.

 

※ 예시 
@Transactional 어노테이션을 선언하는 것 만으로 별도의 코드 추가 없이 트랜잭션 서비스를 사용할 수 있다.
내부적으로 트랜잭션 코드가 추상화되어 숨겨져 있는 것이다.

이렇게 추상화 계층을 사용하여 어떤 기술을 내부에 숨기고
개발자에게 편의성을 제공해주는 것이 서비스 추상화(Service Abstraction)이다.

신기하게도 어떠한 경우라도 @Transactional 어노테이션을 이용하면
트랜잭션을 유지하는 기능을 추가할 수 있다.

이렇게 하나의 추상화로 여러 서비스를 묶어둔 것을 Spring에서
Portable Service Abstraction이라고 한다.

 

 

 

---

 

Spring Framework 계층 구조

 

 

 

 

1. 프레젠테이션 계층 (Presentation Layer)

클라이언트로부터의 HTTP 요청을 수신하고, 해당하는 응답을 주는 계층이다.

어떤 요청을 받았고, 어떤 응답 형태와 데이터를 반환하는지에 대한 책임을 가지고 있어,
URI를 어떤 방식으로 처리할 것인지에 대한 설계가 필요하다.
(UI 연결 및 JSON 응답... 등등)

 

• Get : 외부에서 접근해오는 페이지 / 정보 조회
• Post : 데이터를 처리하는 페이지

 

 

 

2. 서비스 계층

요구사항에 맞게 비즈니스 로직을 작성하고, 해결하는 계층으로, 
서비스의 핵심 로직들이 주로 담겨있다.

 

 

 

3. 데이터 엑세스 계층

Entity를 이용하여 데이터 베이스 구조를 만들었다면, 
데이터 엑세스 계층은 데이터를 저장하거나 조회하는 등(CRUD)을 어떻게 할 것인지를 
정해 DB에 접근한다. (findAll 등으로)

@Repository 어노테이션을 사용해 빈으로 등록하여, 
에러 추상화 등 부가적인 기능을 제공받을 수 있다.

 

 

 

---

 

전체 구조 (package 기준)

 

 

 

 

1. Controller (web)

기능

• 해당 요청 url에 따라 적절한 view와 mapping 처리
• @Autowired Service를 통해 service의 method를 이용
• 적절한 ResponseEntity(DTO)를 body에 담아 Client에 반환

 

 

 

2. Service

기능

• @Autowired Repository를 통해 repository의 method를 이용
• 적절한 Buisness Logic을 처리한다.
• DAO로 DB에 접근하고, DTO로 데이터를 전달받은 다음, 비즈니스 로직을 처리해 적절한 데이터를 반환한다.

 

 

 

3. Repository (DAO)

기능

• 실제로 DB에 접근하는 객체이다.
• Service와 DB를 연결하는 고리의 역할을 한다.
• SQL을 사용(개발자가 직접 코딩)하여 DB에 접근한 후 적절한 CRUD API를 제공한다.

 

 

 

 

 

---

출처

• https://its-ward.tistory.com/entry/Spring-Spring%EC%9D%98-%ED%8A%B9%EC%A7%95%EA%B3%BC-%EA%B3%84%EC%B8%B5-%EA%B5%AC%EC%A1%B0
• https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html
• https://velog.io/@tank3a/%EC%8A%A4%ED%94%84%EB%A7%81-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88%EC%99%80-%EC%8A%A4%ED%94%84%EB%A7%81-%EB%B9%88
• https://velog.io/@meme2367/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC-%ED%95%B5%EC%8B%AC%EA%B8%B0%EC%88%A0-1.-Spring%EC%9D%B4%EB%9E%80
• https://riderdeveloper.tistory.com/17
• https://sabarada.tistory.com/127