스프링부트 핵심가이드 (장정우 지음) 참고하여 쓰는 글입니다.
주의: 개인적으로 공부하며 쓰는 글이라 중간에 느낀점 같은 첨언이 있을 수 있습니다. (쓸데없는말이좀많습니다.)
01 스프링 부트란?
스프링의 핵심 가치
"애플리케이션 개발에 필요한 기반을 제공해서 개발자가 비즈니스 로직 구현에만 집중할 수 있게끔 하는것"
다음과 같은 방법으로 스프링의 핵심 가치를 구현한다.
1. 제어 역전(IoC)
객체의 관리를 컨테이너에 맡겨 제어권이 넘어간 것
=> 제어 역전을 통해 의존성 주입, 관점 지향 프로그래밍이 가능해짐
==> 스프링을 사용하면 객체의 제어권을 컨테이너로 넘기기 때문에 개발자는 비즈니스 로직을 작성하는 데 더 집중할 수 있음
2. 의존성 주입(DI)
사용할 객체를 직접 생성하지 않고 외부 컨테이너가 생성한 객체를 주입받아 사용하는 방식
생성자/필드 객체 선언/setter 메서드를 통한 의존성 주입으로 나뉘고, 스프링은 생성자를 통해 의존성을 주입받는 방식을 권장
3. 관점 지향 프로그래밍(AOP)
여러 비즈니스 로직에서 반복되는 부가 기능을 하나의 공통 로직으로 처리하도록 모듈화해 삽입하는 방식
이처럼 스프링 프레임워크는 기존 개발 방식의 문제를 해결하지만 기능이 많은 만큼 설정이 복잡하다
=> 스프링 부트(String Boot) 등장하여, 별도의 복잡한 설정없이 동작
스프링 부트의 특징
1. 의존성 관리
- 'spring-boot-starter' 라는 의존성을 제공하여, 각 라이브러리의 기능과 관련해 자주 사용되고 서로 호환되는 버전의 모듈 조합을 제공
2. 자동 설정
- 추가된 라이브러리를 실행하는 데 필요한 환경 설정을 알아서 찾아줌
3. 내장 WAS
- 스프링부트의 웹 애플리케이션이 톰캣을 내장함, 필요에 따라 다른 웹 서버(Jetty, Undertow 등)로 대체 가능
4. 모니터링
- 스프링부트 액추에이터 라는 자체 모니터링 도구가 있음. 서비스를 운영하며 해당 시스템이 사용하는 스레드, 메모리, 세션 등 주요 요소들을 모니터링함
02 개발에 앞서 알면 좋은 기초 지식
2.1 서버 간 통신
마이크로서비스 아키텍처
서비스 규모를 작게 나누어 구성한 아키텍처
-> 서비스 기능별로 구분해서 독립적인 애플리케이션을 개발하면 (ex: 블로그 프로젝트, 카페 프로젝트, 메일 프로젝트)
각 서비스 간 통신이 필요함, 즉 서버 간 통신 필요
서버 간 통신
한 서버가 다른 서버에 통신을 요청하는 것, 가장 많이 사용되는 방식: HTTP/HTTPS
2.2 스프링 부트의 동작 방식
근데 스프링부트의 동작 방식까지 내가 알아야 하나? 편하게 쓰는게 목적인데...
사실 이해 안돼서 정리를 못하겠음
지금은 읽어보기만 하고 나중에 공부의 필요성을 느끼면 이 장은 다시 펼치도록 하겠다
2.3 레이어드 아키텍처
프레젠테이션 계층/비즈니스 계층/데이터 접근 계층(+인프라(데이터베이스) 레이어)으로 구성
스프링에서 쓰이는 레이어드 아키텍처
1, 프레젠테이션 계층
- 유저 인터페이스(UI) 계층이라고도 한다.
- 클라이언트와의 접점이 된다
- 클라이언트로부터 데이터와 함께 요청을 받고 처리 결과를 응답으로 전달하는 역할이다.
2. 비즈니스 계층
- 서비스 계층이라고도 한다.
- 핵심 비즈니스 로직을 구현하는 영역이다.
- 트랜잭션 처리나 유효성 검사 등의 작업도 수행한다.
3. 데이터 접근 계층
영속(Persistence) 계층이라고도 한다.
데이터베이스에 접근해야 하는 작업을 수행한다.
솔직히 뭔 말인지 감이 안 옴.. 책에서도 이렇게밖에 설명이 안 되어 있어서
2.4 디자인 패턴
소프트웨어를 설계할 때 자주 발생하는 문제들을 해결하기 위해 고안된 해결책
GoF 디자인 패턴 종류는 다음과 같이 세 가지로 구분된다. (GoF 디자인 패턴 이런게 진짜 있는 말인가 검색하니까 진짜 있네..ㅋㅋ 뭐든 공부해놓으면 좋겠지)
생성 패턴
- 객체 생성에 사용되는 패턴으로, 객체를 수정해도 호출부가 영향을 받지 않게 한다.
구조 패턴
- 객체를 조합해서 더 큰 구조를 만드는 패턴이다.
행위 패턴
- 객체 간의 알고리즘이나 책임 분배에 관한 패턴이다.
- 객체 하나로는 수행할 수 없는 작업을 여러 객체를 이용해 작업을 분배한다. 결합도 최소화를 고려할 필요가 있다.
| 생성 패턴 | |
| 추상 팩토리 | 구체적인 클래스를 지정하지 않고 상황에 맞는 객체를 생성하기 위한 인터페이스를 제공하는 패턴 |
| 빌더 | 객체의 생성과 표현을 분리해 객체를 생성하는 패턴 |
| 팩토리 메서드 | 객체 생성을 서브클래스로 분리해서 위임하는 패턴 |
| 프로토타입 | 원본 객체를 복사해 객체를 생성하는 패턴 |
| 싱글톤 | 한 클래스마다 인스턴스를 하나만 생성해서 인스턴스가 하나임을 보장하고 어느 곳에서도 접근할 수 있게 제공하는 패턴입니다. |
| 구조 패턴 | |
| 어댑터 | 클래스의 인터페이스를 의도하는 인터페이스로 변환하는 패턴 |
| 브리지 | 추상화와 구현을 분리해서 각각 독립적으로 변형케 하는 패턴 |
| 컴포지트 | 여러 객체로 구성된 복합 객체와 단일 객체를 클라이언트에서 구별 없이 다루는 패턴 |
| 데코레이터 | 객체의 결합을 통해 기능을 동적으로 유연하게 확장할 수 있게 하는 패턴 |
| 퍼사드 | 서브시스템의 인터페이스 집합들에 하나의 통합된 인터페이스를 제공하는 패턴 |
| 플라이웨이트 | 특정 클래스의 인스턴스 한 개를 가지고 여러 개의 '가상 인스턴스'를 제공할 때 사용하는 패턴 |
| 프락시 | 특정 객체를 직접 참조하지 않고 해당 객체를 대행(프락시)하는 객체를 통해 접근하는 패턴 |
| 행위 패턴 | |
| 책임 연쇄 | 요청 처리 객체를 집합으로 만들어 결합을 느슨하게 만드는 패턴 |
| 커맨드 | 실행될 기능을 캡슐화해서 주어진 여러 기능을 실행하도록 클래스를 설계하는 패턴 |
| 인터프리터 | 주어진 언어의 문법을 위한 표현 수단을 정의하고 해당 언어로 구성된 문장을 해석하는 패턴 |
| 이터레이터 | 내부 구조를 노출하지 않으면서 해당 객체의 집합 원소에 순차적으로 접근하는 방법을 제공하는 패턴 |
| 미디에이터 | 한 집합에 속한 객체들의 상호작용을 캡슐화하는 객체를 정의한 패턴 |
| 메멘토 | 객체의 상태 정보를 저장하고 필요에 따라 상태를 복원하는 패턴 |
| 옵저버 | 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버 목록을 객체에 등록해 상태가 변할 때마다 메서드 등을 통해 객체가 직접 옵저버에게 통지하게 하는 디자인 패턴 |
| 스테이트 | 상태에 따라 객체가 행동을 변경하게 하는 패턴 |
| 스트래티지 | 행동을 클래스로 캡슐화해서 동적으로 행동을 바꿀 수 있게 하는 패턴 |
| 템플릿 메서드 | 일정 작업을 처리하는 부분을 서브클래스로 캡슐화해서 전체 수행 구조는 바꾸지 않으면서 특정 단계만 변경해서 수행하는 패턴 |
| 비지터 | 실제 로직을 가지고 있는 객체(visitor)가 로직을 적용할 객체(element)를 방문하며 실행하는 패턴 |
디자인 패턴은 우리가 자주 사용하는 라이브러리에 생각보다 많이 쓰입니다. 이 책에서는 간단히 소개하고 넘어가지만 인터넷에서 각 패턴의 예제 코드를 쉽게 찾을 수 있으니 이를 참고해서 구현해보는 것을 권장합니다.
각 패턴을 표로 정리하면서 대학에서 자바프로그래밍 수업을 들으면서 배웠었던 거 같은 프로그래밍 기법? 들이 연상되었다.
나는 그게 교수님의 노하우 정도 인 줄 알았는데 저런 디자인 패턴들이 이미 확립되어 있다는 게 충격이다.........
그럼 코딩 잘하는 사람들은 어떤 패턴을 써서 코딩해야 될지 머릿속에 그려지는 건가..싶다. 근데 그냥 이런식으로 이론을 익혀서 하는 건 아닌 것 같고, 천부적인 재능을 가지거나 아니면 코딩을 몇 십년 하다보면 스스로 깨우치게 되는 건가
지금 내 단계에서는 코딩을 할 때 무슨무슨 패턴을 써야지 이런 식으로 딱 나오진 않는 것 같다.
2.5 REST API
대중적으로 가장 많이 사용되는 애플리케이션 인터페이스
이 인터페이스를 통해 클라이언트는 서버에 접근하고 자원을 조작할 수 있다.
개인적으로 익숙한 단어였는데, 뭔지 몰랐다.
2.5.1 REST 란?
Representational State Transfer
주고 받는 자원(리소스) 에 이름을 규정하고 URI 에 명시해 HTTP 메서드(GET, POST, PUT, DELETE) 를 통해 해당 자원의 상태를 주고받는 것을 의미한다.
2.5.2 REST API 란?
- API : Application Programming Interface, API 를 통해 서버 또는 프로그램 사이를 연결할 수 있다.
- REST API 는 REST 아키텍처를 따르는 시스템/애플리케이션 인터페이스
- REST 아키텍처를 구현하는 웹 서비스를 'RESTful 하다'고 표현한다.
2.5.3 REST의 특징
유니폼 인터페이스
- 일관된 인터페이스를 의미
- REST 서버는 HTTP 표준 전송 규약을 따르기 때문에, 프로그래밍 언어와 상관없이 플랫폼/기술에 종속되지 않고 타 언어, 플랫폼, 기술 등과 호환해 사용할 수 있다.
무상태성
- 서버에 상태 정보(쿠키, 세션) 를 따로 보관하거나 관리하지 않는다.
- 한 클라이언트가 여러 요청을 보내든 여러 클라이언트가 각각 하나의 요청을 보내든 개별적으로 처리한다.
- 서버가 불필요한 정보를 관리하지 않으므로 비즈니스 로직의 자유도가 높고 설계가 단순하다.
캐시 가능성
- REST 는 HTTP 표준을 그대로 사용하므로 HTTP 의 캐싱 기능을 적용할 수 있다.
- 캐싱 기능: 클라이언트에서 캐시에 저장해두고 같은 요청에 대해서는 해당 데이터를 가져다 사용한다.
- 이 기능을 사용하면 서버의 트랜잭션 부하가 줄어 효율적이며 사용자 입장에서 성능이 개선된다.
레이어 시스템
- REST 서버는 네트워크 상의 여러 계층으로 구성된다.
- 서버의 복잡도와 관계없이 클라이언트는 서버와 연결되는 포인트만 알면 된다.
클라이언트-서버 아키텍처
- REST 서버는 API 를 제공하고 클라이언트는 사용자 정보를 관리하는 구조로 분리해 설계한다.
- 이 구성은 서로에 대한 의존성을 낮추는 기능을 한다.
2.5.4 REST 의 URI 설계 규칙
URL 규칙
URI 의 마지막에는 '/' 를 포함하지 않습니다.
옳은 예) http://localhost.com/product
잘못된 예) http://localhost.com/product/
언더바(_) 는 사용하지 않습니다. 대신 하이픈(-) 을 사용합니다.
하이픈은 리소스의 이름이 길어지면 사용합니다.
옳은 예) http://localhost.com/provider-company-name
잘못된 예) http://localhost.com/product/provider_company_name
URI 에는 행위(동사)가 아닌 결과(명사)를 포함합니다.
행위는 HTTP 메서드로 표현할 수 있어야 합니다.
옳은 예) http://localhost.com/product/123
잘못된 예) http://localhost.com/delete-product/123
URI 는 소문자로 작성해야 합니다.
URI 리소스 경로에는 대문자 사용을 피하는 것이 좋습니다.
일부 웹 서버의 운영체제는 리소스 경로 부분의 대소문자를 다른 문자로 인식하기 때문입니다.
파일의 확장자는 URI 에 포함하지 않습니다.
HTTP 에서 제공하는 Accept 헤더를 사용하는 것이 좋습니다.
다음 글에서 스프링부트 개발 환경설정을 알아볼 것이다.
'JAVA > Spring Boot' 카테고리의 다른 글
| #3 h2 데이터베이스 사용해보기 (0) | 2023.08.17 |
|---|---|
| #2 스프링부트 환경 설정 (0) | 2023.08.17 |
