2023. 12. 18. 20:48ㆍ스프링
Spring?
JAVA / Kotlin 기반의 Application Framework이다.
Spring Framework는 최신 Java 기반 엔터프라이즈 애플리케이션을 위한 프로그래밍 및 구성 모델을 제공한다.
Spring의 핵심 요소는 애플리케이션 레벨의 인프라 지원이다. Spring은 개발자가 비즈니스 로직에 집중할 수 있도록 엔터프라이즈 애플리케이션의 "Plumbing(직역: 배관)"에 중점을 둔다.
Framework
Application을 개발하기 위한 규약과 다양한 요소들을 제공하는 틀
Library
Application 개발시 활용가능한 도구(코드)의 집합
Application을 기준으로 Application을 호출하는지, 호출을 당하는지 여부로 구분을 할 수 있다. 즉, Caller 와 Callee의 차이라고 말할 수 있다.
Framework는 Application을 호출하는 Caller 역할을하고, Library는 반대로 Application이 호출을 하는 Callee의 역할을 한다.
결국, Framework은 우리가 Application 관련 코드를 작성하면 이를 알아서 호출해주는 역할을 하고, Library는 우리가 Application 코드를 작성할 때 활용하는 도구다.
Package, Module, Library 순으로 사이즈가 점점 더 커진다고 볼 수 있다.
Package
Package는 관련 클래스 및 인터페이스 집합을 구성하는 네임스페이스입니다. Java, Kotlin에서는 개념적으로 하나의 디렉토리라고 볼 수 있다.
Module
Module은 패키지와 관련 리소스의 모음이다. 하나의 작은 역할을 담당한다.
특히, Java Module은 Application 혹은 API 를 별도의 module로써 패키징하는 매커니즘이다.
Library
Library는 기능의 집합이라 할 수 있다.
여러 개의 모듈로 구성된다.
예를 들어, Collections 라이브러리는 Set module, List module, Map module 등으로 구성된다고 말할 수 있다.
CSR( Client Side Rendering )
라이언트 사이드 렌더링, 말 그대로 클라이언트 측에서 렌더링을 진행한다.
브라우저 측에서 JS를 다운받고, 리액트를 실행시킨다. 모든 로직과 데이터 가져오기, 템플릿, 라우팅과 같은 것들은
서버가 아닌 클라이언트에서 처리가 된다. 완전히 실행이 다 되면 사용자는 화면을 볼 수 있고 작동을 시킬 수 있다.
사용자들은 첫 화면을 보는데 시간이 걸릴 수 있고, 화면을 그리는 코드를 받아서 화면을 그리긴 하지만, 데이터를 받아오진 않는다. SEO(검색엔진최적화(Search Engine Optimization))에는 취약한 편이라 검색이 잘 안될 수도 있다. 애플리케이션이 커짐에 따라 필요한 JavaScript의 양이 증가하는 경향이 있어서, 다운로드 속도가 느려질 수 있다. 하지만 서버의 부하를 줄여줄 수 있는 장점을가지고 있다.
SSR (Server Side Rendering)
서버 사이드 렌더링, CSR과 반대로 서버에서 렌더링을 진행한다.
클라이언트가 사이트에 들어오면 서버측에서 데이터를 가져와서 페이지를 구성한 후 브라우저에 전달한다.
SSR은 클라이언트가 페이지를 이동할 때 서버측에서 데이터를 불러와서 다시 브라우저에게 모든 내용을 전달한다.
그래서 다시 렌더링하지 않아도 되는 부분까지 다시 렌더링을 하는 단점이 있고 서버에서 대부분의 일을 처리하기 때문에 서버의 부하가 심하다는 단점이 있다. SEO(검색엔진최적화(Search Engine Optimization))가 좋다는 장점이 있다.
이러한 CSR과 SSR의 장점을 모두 사용할 수 있는 형태의 Framework 들이 나왔고, 대표적인게 Next.js 이다.
이 두개의 차이는 바로 이 Plumbing 방식의 차이에 있다.
Plumbing을 쉽게 풀어쓰자면, Application의 각 요소들을 조합하는 과정으로, Spring에서는 원래 이 과정을 개발자들이 손수 코드를 통해 표기해줘야한다. 예를들어, 요소 A 다음에 요소 B를 연결하고, 다시 C를 연결하고.. 이런 코드를 작성해줘야하는데,
Spring Boot는 이러한 과정을 개발자들이 손수 할 필요 없이 Spring이 자동으로 할 수 있게 도와주는 Spring의 Extension, 즉 Plumbing을 손쉽게 해주는 도구라고 볼 수 있다!
1) Spring Web Application의 구조
Web Application을 만들기 위해 필요한 요구사항
- 유저 혹은 Frontend Application의 요청을 처리하고, 적절한 응답을 줄 수 있어야 한다.
- 예외 처리를 할 수 있고, 예외가 발생했을 때 적절한 응답을 줄 수 있어야 한다.
- 인증과 인가 처리를 할 수 있어야 한다.
- 비즈니스 로직을 처리할 수 있어야 한다.
- Transaction 관리 전략이 있어야 한다.
- 스토리지(저장소) 및 다른 외부 시스템과 통신할 수 있어야 한다.
인증- 적절한 신원을 파악하고 있는가?에 대한 것이다. 대표적으로 로그인이라 볼 슈 았더
인가- 인증된 사람에 한에서 해당 리소스를 접근 할 수 있는 권한이 있는지 확인하는것이다. 예를 들어 은행 송금할때 본인인지 확인하는 것이다.
위 요구사항들을 처리하기 위해 Spring을 통해 개발할 시 일반적으로 Layer(계층)를 나누는데,
Layer를 나누는 이유는 관심사의 분리(Seperation Of Concerns)를 위해서다.
관심사의 분리를 통해서 코드의 재사용성, 유지보수성을 높일 수 있다.
Layer를 나누는 방식은 여러가지가 있겠지만, 일반적으로 많이 쓰는 방식로, Web Layer, Service Layer, Repository Layer로 구성된다.
Web Layer
Application의 최상위 Layer이다.
Client의 요청을 받고, 응답을 주는 역할을 주로 하고 (i.e. Controllers) 하위 Layer에서 발생한 예외들을 처리하여 적절한 응답을 준다. (i.e. Exception Handlers) 인증과 인가 처리를 담당한다. (i.e. Filters)
Service Layer
Web Layer 하위에 존재하는 Layer이다.
Transaction 경계의 역할을 하며, Application Service, Infrastructure Service로 나누어진다.
Application Service: 요청의 처리에 대한 주요 로직을 담당하고, 최종적으로 응답을 WebLayer에 넘겨주는 역할을 한다.
Infrastructure Service: 데이터 베이스, 이메일 서버 같은 외부 서비스와 통신하는 역할을 한다.
Application Service에서 Infrastructure Service를 사용한다.
Repository Layer
가장 하위에 존재하는 Layer이다.
데이터베이스와 통신하는 역할을 담당한다.
정리하자면 Web Layer가 Service Layer를 호출하고, 다시 Service Layer에서 Repository Layer를 호출하게 되는 구조다.
각 Layer를 호출할 때 어떤 인터페이스를 통해 호출이 되어야 하는가?
크게 보자면 DTO와 Domain Model 이 각 Layer사이의 변수로 넘겨진다고 볼 수 있다.
DTO(Data Transfer Object)
데이터를 담을 수 있는 간단한 객체다.
Application 내에서 각 Layer 사이의 데이터를 전달하는데 쓰이며, 응답과 요청 또한 DTO로 표현될 수 있다.
주로 코틀린에서는 데이터 클래스로 많이 사용한다.
Domain Model
Domain Model은 Domain Service, Entity, VO(Value Object)를 포함하는 개념이다.
Domain Service : 도메인에 대한 특정 로직을 수행하는 Stateless 한 Class 이다. 여기서 도메인은 우리가 만드는 Application을 통해 해결하고자 하는 문제 / 분야라 할 수 있다.
Entity : Database에 저장될 수 있는 Data를 표현하는 객체로, table과 대응된다. Entity의 Instance는 Table의 한 Row와 대응된다.
VO(Value Object) : 값을 표현하는 객체로, Entity와 Lifecycle을 함께한다. Entity가 갖고 있는 속성중 하나라 할 수 있다.
DTO는 Web Layer와 Service Layer에서 사용된다. Web Layer는 DTO를 input으로 받고, DTO를 응답한다. 각각 Request와 Response에 대응된다.
Service Layer는 Web Layer로 부터 DTO 혹은 Basic Type(Int, String …) 을 넘겨 받아 로직을 수행한 후 다시 DTO를 WebLayer에 응답한다. Service Layer는 내부에서 로직을 수행하기 위해 Domain Model을 사용한다.
Repository Layer는 Entity와 BasicType 을 파라미터로 받고, Entity를 응답한다.
Domain Models는 비즈니즈 로직, 즉 민감한 정보가 담겨있기때문에 상위레이어보다 하위 레이어에 노출되게 한다.
2) Spring의 요청 전달 과정
1. Client는 Dispatch Servlet에 Request를 보낸다. 여기서 Request HTTP Request, 대표적으로 Method (GET, POST, PUT, PATCH, DELETE) 와 URL, 그리고 보내는 JSON Data를 포함한다.
참고) 대부분 GET 과 DELETE는 JSON Data 가 포함되지 않는다.
2. Dispatch Servlet은 HandlerMapping을 통해 요청에 대응되는 Controller를 검색하고, 응답을 받는다.
3. 바로 가는 것이 아니라 Handler Adapter를 통해 Controller에 Request에 대한 처리를 요청한다.
4. Controller, Service, Repository를 거쳐 비즈니스 로직을 수행한 후 Response를 응답한다.
5. 다시 Handler Adpater가 응답을 Dispatch Servlet에 전달한다.
6. 최종적으로 HTTP Response 형태의 응답이 Client에 전달된다.
결국, DispatchServlet의 역할이 중요하다는 것이다! DispatchServlet은 FrontController 라고도 하며, 사용자의 요청을 컨트롤하여 다른 컨트롤러에 전달하기 때문이다.
위 그림에서 DispatchServlet, HandlerAdapter, HandlerMapping은 Spring에서 제공하는 영역이고, Controller, Service, Repository는 사용자가 구현하는 영역이다.
어려운거 투성이다 ㅠㅠ 주말을 통해서 미리 듣고 오늘 다시 복습했는데 아직 너무 어렵다,,,
그래도 두번쨰 들을 때는 이게 이런 거구나 싶은 부분은 있다.. 후
제대로 스프링을 들어가니까 헷갈리는 부분도 있고 정신없네
그래도 이번 과제는 퀴즈 푸는거라고 손쉽게 다 맞힐 수 있었다.
처음에 틀린 줄 알았는데,, 내가 너무 일찍 문제를 제출하는 바람에 정답 답안이 바뀌어섴ㅋ 결국은 첨부터 다 맞은거로 되었다 ㅋㅋㅋ 어우 퀴즈 푸니까 확실히 개념이 정리되는 기분이였다
좀 더 찾아봐서 공부도 됐고 내일 한번 더 강의 듣던가 해야지
아 근데 반성해야 하는 부분은 오늘 한 부분을 일찍 끝나서 여유부리다가 ㅋㅋ 잠깐 쉰다는 걸 1시간이나 자버렸다ㅠ 후
다시 얼른 공부해야지 정신차리자 잠깨자,, ㅠㅠ
'스프링' 카테고리의 다른 글
| TIL 20231226 (0) | 2023.12.26 |
|---|---|
| TIL 20231222 (0) | 2023.12.22 |
| TIL 20231221 (0) | 2023.12.20 |
| TIL 20231220 (0) | 2023.12.20 |
| TIL 20231219 (0) | 2023.12.19 |