스프링 간단 공부 정리

우리가 스프링을 왜 사용하는지 장점이 무엇인지 공부를 해 보았습니다.

또 사용하면서 계속 염두에 두고 있어야 할 CLEAN CODE의 원칙중 SOLID에 대해서 간단하게 공부했습니다.

목차

---

1. 스프링의 개념
2. SOLID

스프링의 개념

---

스프링은 다양한 라이브러리를 지원한다

그 중에 필수 기술과 선택 기술이 있는데

대표적으로 필수로 사용하는 라이브러리는

스프링 프레임워크, 스프링 부트 가 있고,

선택적으로 사용하는 라이브러리는

스프링 데이터, 스프링 세션, 스프링 시큐리티, 스프링 RestDocs, 스프링 배치, 스프링 클라우드 등이 있다.

그림으로 나타낸 스프링 기술 라이브러리

그림으로 나타낸 스프링 기술 라이브러리

위에서 설명한 각 라이브러리들에 대해 간단하게 정리해보고자 한다.

스프링 프레임워크

---

기술 특징

• 핵심 기술
• 스프링 DI컨테이너(의존성 주입), AOP, 이벤트, 데이터 바인딩
• 테스트
• 스프링 기반 테스트 지원 - 기존 자바에서 사용하는 JUnit 테스팅을 스프링 기반으로 테스트도 가능하게 해준다
• 데이터 접근 기술
• 트랜잭션, JDBC, ORM지원, XML지원
• 웹
• 스프링 MVC, 스프링 WebFlux
• 기술 통합
• 캐시, 이메일, 원격접근 등등

스프링 프레임워크 기능들을 설명한 참조페이지

최근에는 스프링 부트를 통해 프레임워크의 기술들을 편리하게 사용 가능하게 되었다.

스프링 부트

---

현 시점에서는 스프링을 사용한다면 기본으로 사용한다고 보면 된다고 한다

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

Tomcat같은 웹 서버가 내장돼서 별도의 웹 서버가 필요하지 않게 되었다

빌드 구성을 단순화 하기 위한 starter 종속성을 제공한다 - 이로인해 타임리프, oauth2 등등을 빌드할 때 아래의 형식으로 선언할 수 있음

spring-boot-starter-xxx 빌드 예시
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-security'
    implementation 'org.springframework.boot:spring-boot-starter-oauth2-client'
		implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
}

스프링과 3rd parth(외부)라이브러리가 자동으로 구성된다.(버전업되거나 이러한 부분들 관련해서 자동으로 구성된다.)

참조 페이지

그 외의 스프링 라이브러리

---

• 스프링 데이터
• CRUD기능 사용을 돕는다 - 대표적으로 스프링 데이터JPA가 있다
• 스프링 세션
• 세션기능 편리하게 사용가능
• Security
• 로그인 인증 및 권한 부여, 해킹(세션변조, 클릭재킹, 교차 사이트 요청 위조)으로부터 보호
• Rest Docs Api
• 데이터 구축 편리화(Restful서비스 문서화)
• 스프링 배치
• 트랜잭션 관리, 리소스 관리, 대용량 레코드 처리에 필수적인 재사용 가능한 기능을 제공
• 클라우드
• 클라우드 기술

등등이 있다 더 많은 라이브러리를 보고싶다면 여기를 참조

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

스프링 DI 컨테이너 기술

스프링 프레임워크

스프링 부트, 프레임워크 등을 모두 포함한 스프링 생태계

말하는 상황에 따라 뜻이 다르게 사용될 수 있다.

스프링은 좋은 객체지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크

스프링에서 객체지향 특성중 다형성을 극대화해서 이용할 수 있게 도와주는 프레임워크 이다.

스프링을 들어가기 전 알아두면 좋은 개념

SOLID

---

클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 SOLID라고 한다.

• SRP 단일 책임 원칙단 하나의 책임이라는 것은 모호하다.문맥과 상황에 따라 다르다.
• 클 수 있고, 작을 수 있다.
• 한 클래스는 하나의 책임만 가져야 한다.

중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것

ex) UI변경, 객체의 생성과 사용을 분리

OCP : 개방-폐쇄 원칙

중요!

소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다

이 방식은 다형성을 활용해서 인터페이스를 구현한 새로운 클래스에 새로운 기능을 구현하면 도움이 될 것이다.

이는 지키기 상당히 힘든데 우리는 Spring 컨테이너가 이 부분을 해결하는데 도움을 준다

LSP : 리스코프 치환 원칙

인터페이스의 기능적 신뢰성을 보장해줘야한다.

ex) 자동차는 가속과 감속을 할 수 있지만 0 미만의 속력이 나오면 안된다.

이를 인터페이스로 구현했을 때 0 미만의 속력이 나온다면 LSP를 지키지 못한것

ISP : 인터페이스 분리 원칙

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다

DIP : 의존관계 역전 원칙

중요!

프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다. 의존성 주입은 이 원칙을 따르는 방법 중 하나다.

멤버서비스는 멤버리파지토리만 바라보는 역할에만 의존해야한다는 뜻

우리가 그램그램을 사용하면서 mvc 관련해서 멤버리퍼지토리 등등 각 역할에 맞게만 구현하게 하는 걸 말한다.

쉽게 말해서 구현 클래스에 의존하지 말고 인터페이스에 의존하라는 뜻이다.

해당 개념을 간단하게라도 배운 이유는

스프링이 객체지향의 핵심인 다형성과 SOLID 원칙중 OCP, DIP를 가능하게 할 수 있게 지원을 해준다.

자바만을 통해서 CLEAN CODE를 만들기 위해 해당 OCP, DIP원칙들을 지키며 개발을 한다면 스프링 프레임워크에 있는 DI컨테이너의 필요성을 느끼게 될 수밖에 없다고 한다.

이러한 DI컨테이너의 활용이 스프링 프레임워크(boot x)의 핵심!

이상적으로는 모든 설계에 인터페이스를 부여하는 것이 가장 CLEAN CODE에 가깝다고 한다

하지만 인터페이스를 도입하면 추상화라는 비용이 발생한다.