23_12_19 Spring
심화강의랑 입문강의랑 착각해서 반대로 수강하고 있었다 어쩐지 어렵더라 초반에 이론위주의 내용이다 보니 당연히 봐야 되는건줄 알았다
오늘 배운 것
//Spring
스프링은 자바/코틀린기반의 Application Framework
스프링의 핵심 요소는 애플리케이션 레벨의 인프라 지원
개발자가 비즈니스 로직에 집중할수있도록 엔터프라이즈 애플리케이션의 Plumbing(배관)에 중점을 둔다
//
//라이브러리와 프레임워크의 차이
프레임워크는 애플리케이션을 개발하기 위한 규약과 다양한 요소들을 제공하는틀
라이브러리는
애플리케이션 개발시 활용가능한 도구(코드)의 집합
애플리케이션을 기준으로 호출하는지 호출당하는지의 차이
프레임워크는
애플리케이션을 호출 하고 라이브러리는 애플리케이션에서 호출한다
프레임워크는 애플리케이션 코드를 작성하면 이를 알아서 호출해주고 만들어준다
라이브러리는 애플리케이션을 개발할때 필요에 의해 불러서 사용하는 도구
//
//모듈과 패키지
Package <Module<Library
패키지는 디렉토리의 구성을 뜻하고 관련 클래스와 인터페이스의 집합
모듈은 패키지와 관련 리소스의 모음 하나의 작은 역할 하나의 애플리케이션이있으면 여러 모듈로 나눠서 패키징을 하고 배포를 할수있다
라이브러리는 모듈보다 상위개념 기능의 집합 여러개의 모듈로 구성됨
//
//스프링의 용도
스프링은 Web Application 을 만드는데 특화되어있음
//
//웹생태계의 변화
1세대
서버를 통해 완성된 html과 css 를 로드 페이지 별 완성된 화면ㅇ을 서버에서 불러오기 때문에 페이지 이동시 화면이 깜빡임
2세대
동적인 웹사이트를 구현하기 위해 ajax라는 동적인 웹페이지를 만들기 위한 개발기법이 등장 페이지가 깜빡이지 않고 서버에서 받아온 html위에서 필요한 데이터만을 서버에 재요청하여 변경하는게 가능
3세대
리액트 앵글러 뷰 등의 라이브러리 및 프레임워크가 등장하면서 html css 를 js를 통해 동적으로 생성하는 싱글페이지어플리케이션이 주를 이루게 되었고 이때부터 프론트와 백의 역할이 구분되었다 Frontend Server와 Backend Server 또한 차츰 나뉘어 가게 되었습니다. 이렇게 브라우저에서 Javascript를 읽어 페이지를 렌더링(생성)하는 방식을 CSR(Client Side Rendering) 이라 부른다
4세대
3세대 클라이언트 사이드 렌더링 방식과 반대로html의 내용을 모두 채워서 클라이언트에 전송해주는 방식을 서버사이드렌더링 이라 한다
CSR(Client Side Rendering)은 자바스크립트를 통해 페이지를 불러와야 하기에 첫페이지의 로딩이 느리고 반대로 SSR (Server Side Rendering)은 빠른대신 변경사항 혹은 나머지 페이지를 불러오는 시간은SSR (Server Side Rendering)은 다시 만들어야 하기때문에 느리다
csr은 동적으로 다시 만들어주는 상호작용을 거쳐야 하기때문에 첫페이지의 로딩은 느리나 페이지의 일부를 변경할때 서버에서 해당 데이터만을 요청하면 되기에 이후 구동속도는 빠르다 브라우저들이 가지는 웹 크롤러는 HTML을 읽어 검색 가능한 색인을 만들어 내는데, 웹 크롤러 봇 입장에서는 HTML이 텅텅 비어 있는 것처럼 보여서 색인할만한 콘텐츠가 존재하지 않기에 SEO(Search Engine Optimization에 취약하다
최근에는 이러한 CSR과 SSR의 장점을 모두 사용할 수 있는 형태의 Framework 들이 나왔고, 대표적인게 Next.js 이다
//
//요기는 내가 프론트 공부하면서 익힌 내용 익숙한 내용이 나와서 다행이라고 생각했다//
//스프링의 용도가 어떻게 바뀌었을까
이전에는 html/css같은 리소스를 응답해주는 역할도 하였지만 현재 Data를 응답해주는 역할을 한다 여기서 Data는 여러형태가 될수있지만 현재 대부분 Json 포맷을 사용한다
json은
키값과 벨류를 가지고 있는 데이터 포맷이다
json Data를 클라이언트와 프론트서버의 요청에 따라 적절한 json Data를 응답해주는 역할이다
//
//키오스크 과제를 할때 JSON 파일을 사용하면 해결 될 거 같았는데 처음만지는 난해한 리스트로 하려니까 애를 먹었던게 생각이난다 지금은 쓸수있지만 좀 힘들었다//
//스프링과 스프링부트
스프링에 Plumbing의 방식에서 차이가남
Plumbing은 애플리케이션의 각 요소들을 조합하는 과정이라 할수있다
스프링은 이과정을 개발자들이 표기해줘야 한다 스프링부트는 스프링의 확장프로그램으로서 이런 과정을 스프링에서 자동을 할수있게 해준다
//
//spring 의 구조와 주요기술
WebApplication을 만들기 위한 요구사항
1.유저 또는 Frontend Application의 요청을 처리하고 적절한 응답을 줄수있어야 함
2.에외처리를 할 수 있거 예외가 발생했을 때 적절한 응답을 줄 수 있어야한다
3.인증과 인가처리를 할 수 있어야한다
4.비즈니스 로직을 처리 할 수 있어야한다
5.Transaction 관리 전략이 있어야한다
6.스토리지 및 다른 외부 시스템과 통신할 수 있어야 한다
//
//수도코드? 를 작성하는걸 보여주셨는데 머리가 어질어질했다 무언가 스킬보다는 논리적으로 생각해서 각각의 클래스와 함수를 이어주는게 중요해보였다
//spring의 Layer 구조
레이어를 나누는 이유는
관심사의 분리 를 위해 나눈다 이를 통해 코드의 재사용성과 유지보수성을 높일수 있다
일반적으로Web Layer, Service Layer, Repository Layer로 구성
Web Layer
Application의 최상위 Layer
Client의 요청을 받고 응답을 주는 역할을 한다 (Controllers)
하위 Layer에서 발생한 예외들을 처리하여 적절한 응답을 준다 (Exception Handlers)
인증과 인가 처리를 담당(Filters)
Service Layer
Web Layer 에 하위에 존재하는 Layer
Transaction의 경계의 역할
Application Service, Infrastructure Service 로 나뉜다
Application Service: 요청의 처리에 대한 주요 로직을 담당하고, 최종적으로 응답을 WebLayer에 넘겨주는 역할
Infrastructure Service: 데이터 베이스, 이메일 서버 같은 외부 서비스와 통신하는 역할을 합니다. Application Service에서 Infrastructure Service를 사용한다
Repository Layer
가장 하위에 존재하는 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는 웹레이어와 서비스 레이어 사이에서 사용되고 웹 레이어는 DTO를 input으로 받고 DTO를 응답 Request와 Response에 대응
서비스 레이어는 웹 레이어로 부터 DTO 혹은 베이직타입을 넘겨받아 로직을 수행한후 DTO로 웹 레이어에 응답한다 서비스 레이어는 내부에서 로직을 수행하기 위해 도메인모델을 사용
레포지토리 레이어는 Entity와 베이직타입을 파라미터로 받고 Entity를 응답한다
//
//Spring의 요청 전달과정
1. Client가 Dispatch Servlet에 Request를 보낸다 여기서 Request는 http Request와 https이고 이안에 Method 가 포함되어있고 (GET,POST,PUT,PATCH,DELETE) URL 과 JSON 데이터도 포함한다
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 == FrontController
앞단의 사용자의 요청을 컨트롤하여 다른 컨트롤러로 전달
//
//Spring의 Plumbing방식
DI(Dependency Injection) 의존성 주입
객체가 자체적으로 필요하는 의존성을 생성하는 것이 아니라 외부에서 주입받는 디자인 패턴
객체간의 결합도를 낮추는데 사용한다
주로 Constructor기반의 주입 Field기반주입,Setter기반주입이 있다
주로 Constructor기반의 주입을 사용하는 이유
1.의존되는 객체의 불변성 확보 - 객체의 생성자는 생성시 1회만 호출된다 불변성 확보
2.순환 참조 방지 - 다른방식을 사용해서 객체끼리 참조하고 있는 상황에서 오류가 발생한다 이때 생성자 주입을 사용하게 되면 컴파일 되기전에 에러를 알려주기때문에 생성자주입을 주로 사용한다
3. 테스트코드 작성 - 다른 방식으로 의존성을 주입하게 되면 테스트
Inversion of Control (제어의 역전)
1. 객체의 생성과 생명주기를 외부에서 제어하는 디자인 패턴
2. Framework에서 IoC를 제공할 때 이를 IoC Container라고 부르고 IoC의 방식중 DI 를 주로 사용하기 때문에 최근에는 DI Container 라고 부른다
3.DI Container를 통해 개발자가 작성한 Class의 관리를 신경쓰지 않고 Spring에 맡길 수 있다
//
// Spring Bean
Spring IoC Container가 관리하는 객체
Spring Bean을 등록하는 방법
@Component Annotation을 사용하여 등록한다
Annotation이란 자바와 코틀린에서 사용하는 메타데이터의 일종으로 @로 시작하여 프로그램 코드에 부가적인 정보를 제공한다
여러가지 방법이 있지만 @Component와 @Autowired 를 많이 사용한다
//
//Bean Scopes
Bean Scope는 Bean의 생명주기이고 Bean은 객체이기 때문에 , Instance가 생성되고 이 Instance의 생성주기를 결정하는것이 BeanScope이다
BeanScope는 Singleton 패턴으로 설정되며 특정 클래스가 인스턴스화 될때 해당 클래스의 인스턴스가 하나만 생성 되도록 보장하는 패턴
Bean은 IoC Container 당 하나만 생성 - IoC와 생명주기를 같이한다
기본적으로 싱글톤인 이유는 성능향상과 자원관리이다 인스턴스를 만들고 초기화하는것도 비용이기때문에 만들어진 인스턴스를 재사용한다면 전체적인 성능이 향상되고 메모지자원을 효율적으로 사용할수있다
Singleton이기 때문에 주의해야하는 점
Bean은 내부에 상태정보를 갖지 않는 Stateless 방식으로 생성되어야 한다
상태를 가지고 동시에 두개이상의 요청이 해당 상태를 변경하려 했을때 예측하지 못한 상태로 변할 수 있다
Singleton 이외의 생명주기들 을 개발자가 직접 설정가능
Prototype - 인스턴스를 요청할때 마다 새로운 인스턴스를 생성
Request- Bean의 생명주기를 단일 http reauest 와 함께 한다 새로운 요청이 올때마다 빈이 생성되고 사라짐
Session - Bean의 생명주기를 Http session과 함께함
Application - Bean의 생명주기가 SerbletContext와 함께한다 /Singleton과 다른점은 하나의 Application에서 여러 DispatchServlet을 등록할수있다
//
Spring은 DI pattern을 적용한 Ioc Container를 통해 개발자가 작성한 객체를 Spring Bean 으로 관리하고 Annotation을 붙여 줬을때 이를 관리 대상으로 여길수있다
기본적으로 Singleton으로 Bean의 Instance를 관리하여 필요시의 개발자가 직접 Bean의 생명주기를 설정할수있다
개발자가 Plumbing을 크게 신경쓰지않고 비즈니스 로직에만 집중할수있게 된다
________________________________________________________________________________________________
개념이 너무 어려워서 강의 내용을 타자로 빽빽이를 썼다
조금은 이해 되는듯 하였고 오늘 팀원들과 이야기를 많이 나눴는데 많이 배운것도 있지만 내 공부방식이 조금 잘못된거같다는 생각을 하였다
알고리즘을 풀때 기본적인것도 이해하지못하고 for문과 while 문의 차이라던가 아주 기초적인 부분을 놓치고 급하게 진도 따라간다고 조급하게 움직인것도 같았고 백엔드 개발자가 코드를 작성해서 돌아가게 하는 방식이라던가 이런것도 놓치고 있으니 클래스에서 그렇게 애를 먹었나 싶다
사리분별 못하고 해야할때 덜 하고 안해야할때 쓸데없는 짓을 많이 한거같아 조금 반성하게된 하루다
어려워도 일단 처음부터 다시 천천히 익혀보자 조급하지말고 했던거 다시 한번 해볼것