Spring

Spring과 SpringBoot의 차이

SpringBoot는 Spring Framework 프로젝트를 간편하게 셋업할 수 있는 서브 프로젝트이다.
독립 컨테이너에서 동작할 수 있기 때문에 추가 WAS 설치 없이 내장된 톰캣으로 실행한다.

Spring Framework 특징

자바 개발을 편하게 해주는 어플리케이션 프레임워크이다.
어플리케이션 개발을 하는데 필요한 기능들을 제공해주기 때문에 개발에 집중할 수 있다.

• 경량 컨테이너로 자바 객체를 생성하고 관리를 한다.
• 의존성 주입을 통해 객체 간의 관계를 구성한다.
• 편리한 MVC 구조이다.
• Java 객체와 라이브러리를 관리해준다.

IoC / DI

IoC : 객체의 생성 및 생명주기 관리를 개발자가 아니라 프레임워크가 대신 관리해주는 개념 입니다.
개발자는 객체를 직접 생성하고 관리하는 것이 아니라, 필요한 객체를 프레임워크에게 요청하여 주입받는 방식으로 개발합니다.
DI : 객체 간의 의존성을 Spring 컨테이너가 자동으로 주입해주는 방법을 의미합니다.
개발자가 new 키워드로 직접 객체를 생성하는 것이 아니라, Spring이 객체를 생성하고 필요한 곳에 자동으로 주입합니다.

생성자 주입을 사용하는 이유

1. final 키워드를 사용하면 한 번 주입된 객체를 변경할 수 없다. -> 객체의 의도치 않은 변경문제를 방지
2. Spring 컨테이너 없이도 객체를 직접 생성하여 테스트를 할 수 있다.
3. 필수적인 의존성이 누락될 때 프로그램을 실행하기 전에 문제를 해결할 수 있다.

Setter 주입을 사용하지 않는 이유

1. Setter를 통해 외부에서 객체를 변경할 수 있다.
2. 코드의 명확성이 떨어진다. (어떤 의존성을 필요로 하는지 모름)
3. 필수적인 의존성이 누락될 때 프로그램을 실행해야 문제를 발견할 수 있다.

필드 주입을 사용하지 않는 이유

1. Spring 컨테이너 없이 테스트하기가 어렵다. -> Spring이 자동으로 주입해줘야 하기 때문에
   단위 테스트시 @Mock, 또는 API를 사용해야해서 테스트가 번거롭다.
2. final 키워드를 사용할 수 없어서 객체가 변경될 가능성이 있다.
3. 명확한 의존성 확인이 어렵다.

Spring Container

스프링에서 객체의 생성, 관리, 소멸을 담당하는 핵심 개념이다.
개발자가 객체를 직접 생성하고 관리하는 대신, 스프링 컨테이너가 대신 객체를 관리해준다.

역할

1. 객체(빈) 생성
2. 의존성 주입
3. 객체 생명주기 관리
4. 객체(빈) 싱글톤 관리
   

BeanFactory

가장 기본적인 컨테이너로, 스프링 빈을 생성하고 DI만을 수행한다.

ApplicationContext

BeanFactory의 모든 기능을 포함하면서, 추가적인 기능을 제공한다.

동작 과정

1. 설정 정보를 기반으로 컨테이너가 실행된다.
2. 설정 정보를 참고하여 스프링이 빈을 생성한다.
3. 빈이 생성될 때, 필요한 다른 빈을 자동으로 주입한다.
4. 개발자는 스프링이 제공하는 빈을 가져와서 사용한다.
5. 애플리케이션 종료 시 스프링이 빈을 정리한다.

Spring Bean이란

스프링 컨테이너가 관리하는 자바 객체를 뜻한다.

사용 이유

객체 간의 의존관계를 관리하도록 하는 것이 목적이다.
-> 객체가 의존관계를 등록할 때 스프링 컨테이서에서 해당하는 빈을 찾고, 그 빈과 의존성을 만든다.

Spring Bean Scope란

Bean Scope는 Bean이 존재할 수 있는 범위를 뜻한다.
싱글톤, 프로토타입, request, session, application 등이 있다.

@Component / @Bean 차이

@Component는 class를 기반으로 실행시점에서 인스턴스 객체를 생성한다.
@Bean은 method를 기반으로 메서드에서 반환하는 객체를 인스턴스 객체로 생성한다.

AOP

관점 지향 프로그래밍이란 뜻으로 공통으로 사용되는 기능들을 외부 독립된 클래스로 분리하는것을 의미한다.

Filter와 Interceptor 차이

• Filter
  - DispatcherServlet으로 요청이 되기 전/후에 실행된다. -> Web Context에서 동작
  - 웹 어플리케이션 전역으로 처리되는 작업들을 처리할 수 있다. -> 보안 공통작업, 이미지 압축, 문자열 인코딩
• Interceptor
  - DispatcherServlet에서 Controller로 요청이 가기 전/후에 실행된다. -> Spring Context에서 동작
  - 클라이언트의 요청과 관련된 작업을 처리할 수 있다. -> API호출에 대한 로깅을 남기기, Controller로 넘겨주는 정보 가공
• 공통점 -> Controller에서 작업하기 전 처리된다. 그러나 호출 시점이 다름

Spring MVC

Model - View - Controller 구조인 디자인 패턴이다. 사용자 인터페이스와 비즈니스 로직을 분리시켜서 각자 개발에 집중할 수 있다.

• Model
  - 데이터 처리를 담당하는 영역 (Service와 DAO 영역으로 나누어진다.)
  - Model에서는 View와 Controller의 어떠한 정보도 가지고 있어서는 안된다.
• View
  - 사용자 인터페이스를 담당하여 사용자에게 보이는 부분이다.
  - Model이 가지고 있는 정보를 저장해서는 안되고, Model, Controller 구성 요소를 알아선 안된다.
• Controller
  - 사용자의 요청을 처리하고 Model과 View를 중개하는 역할을 한다.
  • View로 부터 받은 요청을 가공하여 Model에 전달한다.
  • Model로 부터 받은 결과를 View로 넘겨주는 역할을 하며, 에러 발생도 처리한다.
  • Model과 View의 정보를 알고 있어야 한다.

Spring MVC 동작 순서

1. 클라이언트에게 요청이 들어옵니다.
2. 들어온 요청을 DispatcherServlet이 가로챕니다.
3. 가로챈 요청을 HandlerMapping에 보내 처리할 수 있는 Controller를 찾습니다.
4. 찾은 Controller에서 실제 로직을 처리하고 DispatcherServlet에게 View를 반환 합니다.
5. 반환한 View 이름을 ViewResolver가 검색을 해서 View 이름을 찾습니다.
6. 찾은 View 화면을 클라이언트에게 전송해줍니다.

@RequestParam / @RequestBody / @ModelAttribute

• @RequestParam
  - HTTP 요청 파라미터를 받기 위해서 사용한다. 속성 required 기본값이 true라 파라미터가 없을을땐 400 에러가 발생
• @RequestBody
  - JSON 형태인 HTTP body 내용을 MessageConverter를 통해 객체로 변환시켜주는 역할
• @ModelAttribute
  - HTTP 요청 파라미터와 HTTP body 내용을 getter/setter, 생성자를 통해 주입하기 위해 사용한다.

VO / DTO / DAO

• VO (Value Object)
  - 값을 갖고 있는 객체이다. 보통 값을 수정할 수 없는 것으로 한다.
• DTO (Data Transfer Object)
  - VO와 같이 값을 갖고 있는 객체이다.
  - VO는 Read Only 속성을 갖는다. 특정한 비즈니스 값을 담는 객체이다.
  - DTO는 Layer간의 통신 용도로 오고가는 객체를 말한다.
• DAO (Data Access Object)
  - 실제 DB에 접속하는 객체이다. Service와 DB 사이에서 가져온 데이터를 엔티티로 변환시켜 가져온다.

프레임워크와 라이브러리의 차이

프레임워크 : 프로그램을 개발하기 위해 사용되는 틀을 제공하는 프로그램이다.
라이브러리 : 다른 프로그램에서 사용할 수 있는 코드나 함수의 집합을 의미한다.

차이점 : 제어 흐름에 대한 주도권이 누구에게 있느냐에 있다. 프레임워크는 스스로 제어 흐름의 주도성을 갖고 있지만 라이브러리는 개발자가 갖고 있다.

HTTP 와 HTTPS의 차이

HTTP(HyperText Transfer Protocol) -> 웹에서 데이터를 전송하는 프로토콜
둘의 차이점은 보안이 있고 없고의 차이이다.

HTTP

1. 암호화 없음 : HTTP는 데이터를 평문 형태로 전송하기 때문에 중간에서 데이터를 가로챌 수 있다.
2. 포트 번호 : 80
3. 보안 레벨 : 낮음 -> 데이터의 민감한 정보가 노출될 수 있으므로 보안 수준이 낮다.
4. 설정 : HTTPS에 비해 구현과 운영이 단순하다.
   

HTTPS

1. 암호화 있음 : SSL/TLS 프로토콜을 사용해 데이터를 암호화하여 전송한다.
2. 포트 번호 : 443
3. 보안 레벨 : 높음 -> 데이터 전송 중 가로채기를 방지하기 때문에 보안 수준이 높다.
4. 인증서 필요 : 서버의 신원을 확인하는 SSL/TLS 인증서가 필요하다. (사용자 신뢰성 제공)
5. 성능 오버헤드 : 암호화/복호화 과정으로 인해 약간의 성능 오버헤드가 발생할 수 있다.

JPA vs Mybatis

Mybatis

데이터베이스와 상호작용할 때 개발자가 SQL 쿼리를 직접 작성해 사용하며, 데이터 매핑을 위해 XML 또는 어노테이션을 사용한다.

• Object Mapping 기술
• 자바에서 SQL Mapper를 지원해주는 프레임 워크
• SQL문을 이용해서 RDB에 접근, 데이터를 객체화 시켜준다.
• 쿼리문을 XML로 분리
• 복잡한 쿼리문 작성 가능
  -> 객체와 쿼리문 모두 관리해야한다, CRUD 메소드를 직접 다 구현해야함

JPA

객체와 관계형 데이터베이스 간의 매핑을 제공하며, JPQL을 사용한다.

• 자바 ORM의 기술 표준
• 대표적인 오픈소스로 Hibernate
• CRUD 메소드 기본 제공
• 쿼리를 만들지 않아도 됨

SQL 쿼리를 직접 작성하는 것을 선호하거나 데이터베이스 상호 작용에 대한 더 많은 제어를 원하지 않은 이상 JPA를 사용하여 개발을 간소화하고 애플리케이션 성능을 개선할 수 있다.

Cookie / Session

Cookie

쿠키는 클라이언트 로컬에 저장되어 있는 작은 데이터 파일이다.
유효시간이 정해지면 브라우저가 종료되어도 인증이 유지된다.
클라이언트에 300 까지 저장가능, 하나의 도메인에 20개의 값만 가질 수 있다, 하나의 쿠키값은 4KB까지 저장가능

Session

쿠키를 기반으로 하고 있지만, 사용자 정보 파일을 서버 측에서 관리한다.
클라이언트를 구분하기 위해 세션ID를 부여하고 웹 브라우저가 서버에 접속해서 브라우저를 종료할 때 까지 인증상태를 유지한다.
사용자에 대한 정보를 서버에 두기 때문에 쿠키보다 보안이 좋지만, 사용자가 많을수록 서버 메모리를 많이 차지 하게 된다.

동작 방식

Cookie

1. 클라이언트가 페이지를 요청한다.
2. 서버에서 쿠키를 생성한다.
3. 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려준다.
4. 넘겨받은 쿠키는 클라이언트가 가지고 있다가 다시 서버에 요청할 때 요청과 함께 쿠키를 전송한다.
5. 동일 사이트 재방문 시 클라이언트의 PC에 해당 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송한다.

Session

1. 클라이언트가 페이지에 요청한다.
2. 서버는 접근한 클라이언트의 Cookie를 확인하여, 클라이언트가 해당 세션ID를 보냈는지 확인한다.
3. 세션ID가 존재하지 않는다면 서버는 세션ID를 생성해 클라이언트에게 넘겨준다.
4. 클라이언트는 서버로부터 받은 세션ID를 쿠키에 저장한다.
5. 클라이언트는 서버에 요청시 이 쿠키의 세션ID 값을 같이 서버에 전달한다.
6. 서버는 전달받은 세션ID로 세션에 있는 클라이언트 정보를 가지고 요청을 처리 후 응답한다.

차이점

1. 저장위치

쿠키 - 클라이언트
세션 - 서버

2. 보안

쿠키 - 보안 취약
세션 - 비교적 보안성이 높음

3. 라이프 사이클

쿠키 - 만료기간이 있고 브라우저를 종료해도 정보가 유지될 수 있다.
세션 - 만료기간을 정할 수 있지만, 브라우저가 종료되면 만료기간에 상관없이 삭제된다.