Spring?
엔터프라이즈용 Java 애플리케이션 개발을 편하게 할 수 있게 해주는 오픈소스 경량급 애플리케이션 프레임워크
어..근데 프레임워크가 뭐지?
어떠한 목적을 쉽게 달성할 수 있도록 해당 목적과 관련된 코드의 뼈대를 미리 만들어둔 것
즉, Spring이라는 것은
"대형 비즈니스 시스템을 만들 때, 개발자가 복잡한 설정이나 반복되는 노가다에 신경 쓰지 않고 자바 문법(POJO)으로만 핵심 기능을 짤 수 있도록 튼튼한 뼈대와 자동 조립 기능을 무료로 제공하는 도구" 를 말한다!
API vs 라이브러리 vs 프레임워크
-
FrameWork: "건물의 뼈대"
FrameWork의 핵심은 "제어의 역전(IoC)" 이다.
즉, 프레임워크가 내가 짜놓은 코드를 호출한다는 것. -
라이브러리: "공구함의 도구" - 자주 쓰는 기능을 미리 만들어놓은 함수나 클래스의 모음
라이브러리의 핵심은 "내가 라이브러리를 호출" 한다는 것. -
API: "점원의 메뉴판" - 프로그램 간의 통신을 위한 프로그램
API의 핵심은 "추상화 + 캡슐화" 이다.
여기서 헷갈릴수도 있는 포인트!
"제어권을 누가 갖고 있는지" 를 봐야한다!
IoC(Inversion of Control)
스프링 프레임워크는 '제어권'을 갖고 있다.
그래서 개발자가 프레임워크가 정해놓은 대로 코드를 작성하고 삽입하면,
실제 실행 흐름은 프레임워크가 관리한다.
이것이 바로 "IoC: 제어의 역전" 이다.
그래서 프레임워크를 사용하면 객체의 생명 주기를 모두 프레임워크에 위임할 수 있어서 프레임워크가 흐름을 제어하는 구조가 된다.
IoC 컨테이너
IoC 컨테이너의 작동방식
- 순수한 자바 클래스(POJO)를 작성한다.
- 클래스 내부에 다른 클래스가 필요하다면? 생성자나 Setter으로 받을 준비만 함
- 클래스 객체들 간의 연관성 지정을 해준다.
- @Component / @Service / @Repository: "이 클래스를 인스턴스로 만들어서 빈(Bean)으로 등록해."
- Autowired: "이 구멍에 맞는 부품을 컨테이너 창고에서 찾아서 꽂아줘."
- @Configuration / @Bean: "내가 직접 객체를 만드는 로직을 짤 테니, 그 결과물을 빈으로 취급해."
- SpringApplication.run()이 실행됨
DI(Dependency Injection)
- IoC가 “제어권을 외부로 넘긴다”라는 원칙이라면,
- DI는 IoC를 실현하는 방법 중 하나 이다.
1. 직접 만드는 방식 (의존성 발생)
예를 들어, 일반원두를 사용하는 CoffeeMachine 클래스가 만들어져 있는 상황.
- 문제점
일반원두 라는 클래스가 없으면 아무것도 못한다.
디카페인으로 바꾸고 싶다면? 코드 자체를 뜯어 고쳐야 함.
2. 외부에서 주입받는 방식 (DI)
CoffeeMachine은 자기가 쓸 원두를 정해놓지 않는 상황.
-
스프링이라는 관리자가 창고에서 원두를 꺼내서 기계의 생성자나 필드에 툭 던져놓는 것, 이것이 주입이다.
-
장점
스프링 설정만 바꿔서 원두를 변경할 수 있다 (유연함)
테스트용 가짜 원두(Mock)를 주입해서 테스트 하는 데에 용이함
객체들이 서로의 정체를 몰라도(인터페이스만 아니까) 조립 가능함 (부품화)
DI 컨테이너
위에서 DI는 알았다. 그렇다면 DI 컨테이너는 뭘까?
객체를 직접 만들지 않고 외부에서 넣어주는(DI) 방식을 자동화해주는 객체 관리 기구
DI컨테이너의 핵심 역할
- 객체 생성: @Component 스티커가 붙은 클래스들을 읽어서 메모리에 인스턴스를 올린다.
- 의존성 탐색: 어떤 객체가 어떤 부품(@AutoWired)을 필요로 하는지 살펴본다.
- 조립: 찾은 부품들을 필요한 곳에 툭 꽂아준다(주입).
- 수명 관리: 객체가 하나만 있어야 하는지, 쓰고 버려야 하는지 결정하고 관리한다.
서블릿(Servlet)
서블릿?
자바 서블릿(Java Servlet)은 웹페이지를 동적으로 생성하는 서버 측 프로그램
다른 말로는, 웹 브라우저의 요청(HTTP Request)을 받아서 실행되도록 설계된 특수한 자바 클래스
서블릿의 동작 방식
- 클라이언트의 요청(HTTP Request)
- 어떤 페이지를 원하는지(URL), 어떤 방식인지(GET/POST), 로그인 정보는 뭔지 등이 담겨있음
- 서버의 대문인 Web Server에 먼저 도착
- 서블릿 컨테이너의 개입 (객체 생성)
- Web Server는 "이건 동적인 처리가 필요하네?"라고 판단하고 요청을 서블릿 컨테이너(WAS, 예: Tomcat)로 넘김
- HttpServletRequest: 사용자가 보낸 데이터를 담는 객체
- HttpServletResponse: 응답을 담아 보낼 빈 객체
- 이 두 객체는 요청일 올때마다 생성되고 끝나면 버려짐
- 담당 서블릿 찾기 (Mapping)
- 컨테이너는 설정파일(web.xml) or 어노테이션(@WebServlet)을 뒤져서, 이 URL을 처리할 서블릿 객체가 누구인지를 찾음
- 해당 서블릿 객체가 없다면? init()으로 새로 만들고,
- 있다면? 재사용 -> 싱글톤 방식
-
Service() 호출과 스레드 할당
- 컨테이너는 해당 요청을 처리하기 위해 스레드(Thread)를 하나 할당하고, 서블릿의 Service()함수를 호출
- Service()는 요청이 GET인지 POST인지 확인해서, doGet()이나 doPost() 메서드로 일을 넘겨줌
- 그리고 나서, 내가 짠 코드가 실행되면서 HttpServletResponse 객체에 결과물을 채워넣음
-
응답 전송 및 정리
- 컨테이너는 HttpServletResponse 객체에 담긴 내용을 HTTP Response 형태로 변환해서 브라우저로 쏴줌.
- 전송 완료 시, Request와 Response 객체는 메모리에서 삭제
- 서블릿 객체 자체는 죽지않고 다음 요청을 기다림
빈(Bean)
빈(Bean): 스프링 컨테이너(ApplicationContext) 가 대신 생성해주고, 필요한 곳에 조립(DI)해주며, 죽을 때까지 관리해주는 객체
Bean으로 등록하여 관리하는 방식
-
자동 빈 등록
- 클래스 위에 '어노테이션' 만 붙여놓으면 스프링이 알아서 "어? 이거 Bean이네?" 하고 객체를 만들어서 메모리에 올려둠
- 어노테이션 - @Component, @Controller, @Service, @Repository
-
수동 빈 등록
- @Configuration이 붙은 설정 클래스 안에서, 메서드 위에 @Bean을 붙임
- 스프링이 설정 클래스를 읽으면서 @Bean이 붙은 메서드를 실행하고, 그 리턴값(인스턴스)을 빈으로 등록
DispatcherServlet
Front Controller 패턴을 구현한 서블릿으로, 모든 HTTP 요청을 받고나서, 적절한 Controller로 전달하고, 로직을 실행한 후 응답을 생성
동작 방식
사용자가 /api/members라는 URL로 회원 목록을 요청했다고 가정.
-
요청 가로채기
- 톰캣이 HTTP Resquest를 받으면, 무조건 DispatcherServlet으로 넘김
-
담당자 탐색 (HandlerMapping)
- /api/members URL을 처리할 수 있는 @RestController 클래스의 특정 메서드를 찾아냄
-
업무 위임 (HandlerAdapter)
- 찾아낸 컨트롤러의 메서드를 직접 호출하지 않고, HandlerAdapter를 통해서 실행시킴
- 이때 HTTP 요청에 들어있던 JSON 데이터나 파라미터들을 네가 짠 컨트롤러 메서드의 파라미터 규격에 맞게 변환해서 꽂아줌
-
로직 실행, 반환
- 내가 짠 컨트롤러 로직이 실행되고, 결과물을 DispatcherServlet에 던져줌
-
응답 데이터 변환, 전송 (ViewResolver / HttpMessageConverter)
- 현대적인 REST API 서버에서는 반환받은 자바 객체를 브라우저가 알아먹을 수 있는 JSON 포맷으로 직렬화(Serialization)한 뒤, HTTP Response 바디에 욱여넣어 클라이언트에게 쏴줌
