시작하기 전

스프링이란

<aside> 💡

스프링 생태계

여러 가지 기술들의 모음

핵심

스프링 프레임 워크, 스프링 부트

모든 기술을 쉽게 사용할 수 있도록 도와주는게 스프링 부트

선택

스프링 데이터 - CRUD를 편리하게 사용할 수 있도록 해주는 기술, Spring data JPA 많이 사용

스프링 세션 - 세션 기능 잘 사용할 수 있도록

스프링 시큐리티 - 보안과 관련된 것

스프링 Rest Docs - API 문서화를 편리하게 해주는 것

스프링 배치 - 배치 처리에 특화된 기술

스프링 클라우드 - 클라우드 기술에 특화된 기술

</aside>

<aside> ❗

스프링 프레임 워크

핵심 기술

스프링 DI 컨테이너, AOP, 이벤트, 기타

웹 기술

스프링 MVC, 스프링 WEBFlux

데이터 접근 기술

트랜잭션, JDBC, ORM 지원, XML 지원

기술 통합

캐시, 이메일, 원격접근, 스케줄링

테스트

스프링 기반 테스트 지원

언어

코틀린, 그루비

</aside>

<aside> ❗

스프링 부트

스프링을 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용

단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성

Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨

→ 빌드하고 서버 띄우는 거 편리하게 해줌 // 별도의 톰켓을 사용할 필요가 없음

손쉬운 빌드 구성을 위한 starter 종속성 제공

→ 쉽게 종속성 설정 가능 (필요한 거 알아서 가져온다.)

스프링과 써드 파티(3rd parth)(외부) 라이브러리 자동 구성

→ 스프링 프레임워크와의 외부 라이브러리 버전을 자동으로 구성

메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공

→ 모니터링을 스프링 부트가 기본적으로 제공

관례에 의한 간결한 설정

**

스프링 부트는 스프링 프레임워크와 별도로 사용할 수 있는 것이 아님

→ 스프링 부트는 여러 스프링 프레임 워크 기술들을 편리하게 사용할 수 있는 기능을 제공하는 것

</aside>

<aside> ❗

스프링 단어 ?

스프링이라는 단어는 문맥에 따라 다르게 사용된다.

• 스프링 DI 컨테이너 기술
• 스프링 프레임워크
• 스프링 부트, 스프링 프레임워크 등을 포함한 스프링 생태계 </aside>

<aside> ❗

스프링은 왜 만들었나 ??

핵심 개념

이 기술을 왜 만들었는가 ??

이 기술의 핵심 컨셉은 ??

→ 핵심 컨셉을 이해해야 내 것이 된다. !!!!

스프링의 핵심 개념, 컨셉

• 스프링은 자바 언어 기반의 프레임워크
• 자바 언어의 가장 큰 특징 - 객체 지향 언어
• 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
• 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크

**

스프링은 객체 지향 프로그래밍을 잘 할 수 있게 도와주는 도구

EJB를 사용하면 객체 지향 특징을 살리지 못함

</aside>

<aside> ❗

좋은 객체 지향 프로그래밍이란 ??

추상화, 캡슐화, 상속, 다형성

객체 지향 프로그래밍

여러 개의 독립된 단위인 객체들의 모임으로 파악하고자 하는 것

각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.(협력)

프로그램을 유연하고 변경이 용이하게 만든다.

</aside>

<aside> ❗

유연하고 변경이 용이

컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법을 의미

→ 재사용성, 상속, 다형성

</aside>

<aside> ❗

다형성

• 실세계와 객체 지향을 1:1로 매칭 X
• 그래도 실세계의 비유로 이해하기에는 좋음
• 역할과 구현으로 세상을 구분

역할 - 인터페이스

구현 - 인터페이스를 구현한 객체

자동차 예제

자동차가 변경되어도 운전자의 역할은 바뀌지 않는다. ( 차가 바뀌어도 운전할 수 있음 )

즉, 운전자는 **자동차 인터페이스(자동차 역할)**에만 의존적

운전자는 자동차 내부 구조 몰라도 된다.

내부가 바뀌더라도 운전자는 자동차 인터페이스에 대해서만 알면 사용하는데 문제 없음

즉, 클라이언트에 영향을 주지 않고 새로운 기능을 제공할 수 있음

→ 역할과 구현으로 세상을 구분하기 때문에 가능

→ 새로운 자동차가 나와도 클라이언트는 바뀔 필요가 없음

공연 무대

로미오 역할, 줄리엣 역할

배우는 대체가 가능해야 함 → 변경, 대체 가능성 생김

로미오 역할을 하는 배우는 줄리엣 역할을 누가할지 상관하지 않아도 됨

즉, 서버의 구현이 바뀐다고 해서 클라이언트의 역할이 바뀌지 않는다.

→ 유연하고 변경이 용이하다는 의미

</aside>

<aside> ❗

역할과 구현을 분리

역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며, 변경도 편리해진다.

장점

• 클라이언트는 대상의 역할(인터페이스)만 알면된다.
• 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
• 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
• 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

자바 언어

다형성을 활용하여 역할과 구현을 분리

• 역할 - 인터페이스
• 구현 - 인터페이스를 구현한 클래스, 구현 객체

객체를 설계할 때, 역할과 구현을 명확히 분리

객체 설계 시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기

객체의 협력이라는 관계부터 생각

혼자 있는 객체는 없다.

클라이언트 : 요청, 서버 : 응답

수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다.

클라이언트가 요청한 행위를 하는게 응답을 하는 것 (꼭 응답을 보내줄 필요는 없음)

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>

<aside> ❗

</aside>