내배캠 4주 2일차

오늘은 스프링에 대해서 간단하게 뭔지 배웠다.

좀 처음보는 내용도 많구 개념도 처음 보는 것이 많아서 이해가 잘 가거나 벌써 다 외운거는 아니지만 그래도 스프링이 뭔지에 대해서 간단하게 알게된거 같다.

내일부터는 스프링에 대해 더 자세하게 배울 거 같다.

아래는 배우면서 메모한 것이다.

라이브러리와 프레임워크 차이
애플리케이션 관점에서 호출할 수 있으면 라이브러리, 호출 당하면 프레임워크다.
또한 프레임워크는 라이브러리를 포함한다.
라이브러리든 프레임워크든 사용자의 편의를 위해 있다.

패키지, 모듈의 차이
패키지는 클래스 및 인터페이스의 집합이다. 디렉토리(폴더)와 비슷한 개념이다.
모듈은 패키지와 관련된 리소스의 모음이다. --> 하나의 기능을 담당한다.
라이브러리는 기능의 집합이다. --> 1개 이상의 모듈이 모여 라이브러리가 된다.

스프링?
스프링은 프레임워크에서 웹을 담당한다. --> 웹 담당 일찐 ㄷㄷ..

/*
웹의 변화 - TMI

1세대
서버를 통해서 html과 css를 불러와서 페이지를 표시했다.
페이지별로 완성된 화면을 불러오기 때문에 이동 시 마다 화면이 깜빡였다.

2세대
동적인 웹 사이트를 만들기 위해서 Ajax라는 개발 기법이 생겼다. --> 1세대는 정적이라는 뜻
때문에 화면이 깜빡이지 않고 필요한 부분(데이터)만 서버로부터 받아와 그 부분만 수정한다.

3세대
여러 프레임워크가 등장해서 html, css, JavaScript를 통해 동적으로 생성하는 SPA(Single Page Application)이 주를 이뤘다.
이때부터 프론트엔드와 백엔드 역할이 나뉘게 된다.
프론트는 클라이언트(웹 브라우저)로부터 html, css, js를 보내준다
백엔드는 클라이언트로부터 데이터를 보내준다
브라우저에서 js를 읽어 페이지를 랜더링 하는 방식을 CSR(Client Side Rendering)이라고 한다.

4세대
3세대의 CSR 방식과 반대로 html 내용을 다 채워서 Client에 전송하는 방식을 SSR(Server Side Rendering) 방식이라고 한다.
CSR는 JS로부터 페이지를 불러오므로 시작할 때 느리다.
SSR는 시작할 때는 빠르나 변경사항이 존재하면 다시 처음부터 만들어야하기 때문에 오래 걸린다.
CSR은 SEO(Search Engine Optimization)에 취약하다. --> 검색엔진(구글, 네이버 등)
최근에는 CSR과 SSR의 장점을 모두 사용하는 프레임워크가 등장했다.
*/

예전 스프링은 html과 css를 넘겨줬지만 현재는 Data를 주로 넘겨준다.
이때 형식은 JSON 포맷을 이용한다.
JSON은 딕셔너리/ Map과 같은 역할이다.
Key 값에는 무조건 String 형식이 온다.
Value에는 Number, String, boolean, Array, Object, Null이 온다.

스프링과 스프링 부트?
스프링과 스프링 부트는 Plumbing 방식의 차이가 있다.
    ==> Plumbing(배관)이라는 뜻으로 각 요소를 조합하는 방법이다.
스프링은 사용자가 직접 요소를 연결한다.
그러나 스프링부트는 스프링이 자동적으로 연결해준다.
따라서 스프링 부트는 스프링의 Extension이다.


Web Application을 만들기 위한 필요 요구사항
1. 유저 혹은 Frontend Application의 요청을 처리하고, 적절한 응답을 줘야한다.
2. 예외처리를 할 수 있고 예외가 발생했을 때 적절한 응답을 줘야한다.
3. 인증과 인가를 처리할 수 있어야한다.
4. Transaction 관리 전략이 있어야한다.
5. 스토리지 및 다른 외부 시스템과 통신이 가능하다.

스프링의 레이어 구조
레이어를 왜 나눌까?
관심사의 분리를 하기 위해서 레이러를 분리한다. --> 기능별로 나눈다.
레이어를 나눔으로써 코드의 재사용성, 유지보수성이 늘어난다.

일반적인 웹에서는 Web, Service, Repository Layer로 나뉜다.

Web Layer
Application의 최상단 Layer이다.
Client의 요청을 받고, 응답을 해준다. --> Controller
하위 Layer에서 발생한 예외를 처리하여 적절한 응답을 준다.
인증과 인가를 담당한다.

Service Layer
Web 하위에 존재한다.
Transaction의 경계의 역할을 한다.
Application Service, Infrastructure Service로 나뉜다.

Repository Layer
가장 하위에 존재한다.
데이터 베이스와 통신하는 역할이다.

DTO와 Domain Model
DTO (Data Transfer Object)
데이터를 담을 수 있는 간단한 객체이다.
Application 내에서 각 Layer 사이의 데이터를 전달할 때 사용된다.

Domain Model
Domain Model은 Domain Service, Entity, VO(Value Object)를 포함하는 개념이다.
Domain Service는 도메인에 대한 특정 로직을 수행하는 Stateless한 Class이다. 도메인은 우리가 만드는 Application을 통해 해결하고자 하는 문제/ 분야이다.
Entity는 Database에 저장될 수 있는 Data를 표현하는 객체로, table과 대응된다.
VO는 값을 표현하는 객체로 Entity와 Lifecycle을 함께한다.


DI와 IOC
DI는 Dependency Injection으로 의존성 주입이라고 한다.
객체가 자체적으로 필요로 하는 의존성을 생성하는 것이 아니라, 외부에서 주입받는 디자인 패턴이다.
객체간의 결합도를 낮추기 위해 사용된다.
DI에는 Constructor(생성자), Field(변수), Setter(함수) 주입이 있다.
주로 Constructor 방식을 사용한다.
1. 의존되는 객체의 불변성 확보
2. 순환 참조 방지
3. 테스트 코드 작성의 용이

IOC는 Inversion Of Control으로 제어의 역전이다.
제어의 역전은 라이브러리와 프레임워크의 것과 비슷하다.
사용자가 코드를 부르는 것이 아닌 흐름에 맞춰 사용자가 불리는 것처럼 객체의 생성과 생명주기를 외부에서 제어하는 디자인 패턴이다.
IoC를 구현하는 방법은 여러가지가 있고 그 중 하나가 DI이다.
FrameWork에서 IoC를 제공할 때 이를 IoC Container라고 한다.


Spring Bean이란?
Spring IoC Contatiner가 관리하는 객체를 Spring Bean이라고 한다.

Spring Bean을 등록하는 방법
1. 어노태이션인 @Component를 이용한다.
    @Component
    class Dependency{}
2. Bean Configuration 파일을 활용해 Bean을 등록할 수있다.
    @Configuration
    class Dependency() {

    @Bean
    fun exam(){}
    }

Spring Annotation의 종류
엄청 많다.
Component, ComponentScan, Bean, Configuration, Autowired, Quarifier ...

Bean Scopes
Bean Scope는 Bean의 생명주기를 말한다.
Bean은 기본적으로 "객체"이므로 Instance가 생긴다.
이 Instance의 생명주기를 결정하는 것이 Bean Scope이다.

Bean Scope는 기본적으로 Singleton으로 설정된다.
Singleton은 디자인 패턴의 하나로 인스턴스가 하나뿐이다.
따라서 모든 인스턴스 변수는 하나의 인스턴스(주소값)을 참조한다.
Spring에서 Bean은 IoC Container당 하나만 생성되고 IoC와 생명주기를 같이한다.

Singleton인 이유는 무엇일까?
큰 이유로는 성능향상 및 자원관리이다.
Singleton이 아니라면 인스턴스를 생성할 때 마다 매번 메모리가 소모되므로 자원소모가 생기고 누적되면 성능저하가 된다.
따라서 Singleton이기 때문에 stateless인 상태가 되야한다.
상태(멤버변수, 프로퍼티)가 있다면 여러 곳에서 인스턴스에 접근해 상태를 변경하면 문제가 생긴다.
Singleton외에 여러 생명주기가 있다.
Prototype, Request, Session, Application