From e0aebda916dfe91c372399350b258d18b74126d0 Mon Sep 17 00:00:00 2001 From: Jiwon Woo <145983280+jiwonniy@users.noreply.github.com> Date: Wed, 4 Dec 2024 18:03:26 +0900 Subject: [PATCH] =?UTF-8?q?Docs=20:=2008=EC=9E=A5=5F=EC=8A=A4=ED=94=84?= =?UTF-8?q?=EB=A7=81=EC=9D=B4=EB=9E=80=5F=EB=AC=B4=EC=97=87=EC=9D=B8?= =?UTF-8?q?=EA=B0=80.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...64\354\227\207\354\235\270\352\260\200.md" | 229 ++++++++++++++++++ 1 file changed, 229 insertions(+) create mode 100644 "\354\232\260\354\247\200\354\233\220/08\354\236\245_\354\212\244\355\224\204\353\247\201\354\235\264\353\236\200_\353\254\264\354\227\207\354\235\270\352\260\200.md" diff --git "a/\354\232\260\354\247\200\354\233\220/08\354\236\245_\354\212\244\355\224\204\353\247\201\354\235\264\353\236\200_\353\254\264\354\227\207\354\235\270\352\260\200.md" "b/\354\232\260\354\247\200\354\233\220/08\354\236\245_\354\212\244\355\224\204\353\247\201\354\235\264\353\236\200_\353\254\264\354\227\207\354\235\270\352\260\200.md" new file mode 100644 index 0000000..d88732b --- /dev/null +++ "b/\354\232\260\354\247\200\354\233\220/08\354\236\245_\354\212\244\355\224\204\353\247\201\354\235\264\353\236\200_\353\254\264\354\227\207\354\235\270\352\260\200.md" @@ -0,0 +1,229 @@ +# 8장 스프링이란 무엇인가? +1. [스프링의 정의](#81-스프링의-정의) +2. [스프링의 목적](#82-스프링의-목적) +3. [POJO 프로그래밍](#83-pojo-프로그래밍) +4. [스프링의 기술](#84-스프링의-기술) + + +
+ +## 8.1 스프링의 정의 +스프링에 대해 가장 잘 알려진 정의는 다음과 같다. + +### **자바 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크** + +이 정의를 하나씩 풀어서 살펴보자 + +#### 💡 애플리케이션 프레임워크 +특정 계층이나 기술 업무 분야에 국한되지 않고 애플리케이션의 전 영역을 포괄하는 범용적인 프레임워크를 말한다. +애플리케이션 프레임워크는 애플리케이션 개발의 전 과정을 빠르고 편리하며 효율적으로 진행하는데 일차적인 목표를 두는 프레임워크다. +애플리케이션의 전 영역을 관통하는 일관된 프로그래밍 모델과 핵심 기술을 바탕으로 해서 각 분야의 특성에 맞는 필요를 채워주고 있기 때문에 애플리케이션을 빠르고 효과적으로 개발할 수가 있다. + +#### 💡 경량급 +가볍다고 하는 이유? -> 불필요하게 무겁지 않다는 의미! +예전의 EJB에 반해 스프링은 가당 단순한 서버환경인 톰캣이나 제티에서도 완벽하게 동작한다. +스프링의 장점은 그런 가볍고 단순한 환경에서도 복잡한 EJB와 고가의 WAS를 갖춰야만 가능했던 엔터프라이즈 개발의 고급 기술을 대부분 사용할 수 있다는 점이다. +경량급이라는 의미는 스프링을 기반으로 제작되는 코드가 상대적으로 작고 단순하다는 뜻이기도 하다. + +> **📕 예전의 EJB**
+ 기술에 대한 과도한 욕심으로 인해 개발환경과 운용서버, 개발과 빌드, 테스트과정, 작성된 코드 모두를 매우 무겁고 복잡하게 만들었다. + +#### 💡 자바 엔터프라이즈 개발을 편하게 +스프링은 근본적인 부분에서 엔터프라이즈 개발의 복잡함을 제거해내고 진정으로 개발을 편하게 해주는 해결책을 제시한다. +엔터프라이즈 개발의 근본적인 문제점에 도전해서 해결책을 제시한다는 것이 기존 기술의 접근 방법과 스프링의 접근 방법의 차이점이다. +스프링은 엔터프라이즈 개발의 기술적인 복잡함과 그에 따른 수고를 제거해준다. + +#### 💡 오픈소스 +스프링은 지금도 여전히 오픈소스 개발 모델과 오픈소스 라이선스를 가지고 개발되고 있다. +개발과정에 많은 사람이 자유롭게 참여한다는 것이 오픈소스 프로젝트로서 스프링이 가진 장점이다. +공개된 커뮤니티의 공간 안에서 투명한 방식으로 다양한 참여를 통해 개발되기 때문에 매우 빠르고 유연한 개발이 가능하다. + +하지만 **단점**도 있다. +- 지속적이고 안정적이 개발이 계속될지 불확실함. + +
+ +### 8.2 스프링의 목적 +경량급 프레임워크인 스프링을 활용해서 +엔터프라이즈 애플리케이션 개발을 편하게 하는 것이다. +그렇다면 굳이 스프링을 사용해서 엔터프라이즈 애플리케이션 개발을 편하게 하려는 이유는 뭘까? + +### 🍃 엔터프라이즈 개발의 복잡함 + +#### 복잡함의 기본적인 이유 +1. 기술적인 제약조건과 요구사항이 늘어가기 때문이다. +- 순수한 비즈니스 로직을 구현하는 것 이외에도 기술적으로 고려할 사항이 많다. +- 웹을 통한 사용자 인터페이스뿐만 아니라, 타 시스템과의 자동화된 연계와 웹 이외의 클라이언트와의 접속을 위한 리모팅 기술도 요구됨 +2. 엔터프라이즈 애플리케이션이 구현해야할 핵심기능인 비즈니스 로직의 복잡함이 증가하기 때문이다. + + +#### 복잡함을 가중시키는 원인 +- 복잡하다는 건 단지 양이 많고 어렵다는 뜻이 아니라, 세부요소가 이해하기 힘든 방식으로 +얽혀있고 그래서 쉽게 다루기 어렵다는 의미다. +- 근본적인 비스니스 로직과 엔터프라이즈 기술이라는 두가지 복잡함이 한데 얽혀 있음. + +### 🍃 복잡함을 해결하려는 도전 + +#### 제거될 수 없는 근본적인 복잡함 +- 엔터프라이즈 개발의 근본적인 복잡함의 원인은 제거할 대상은 아니다. +- 대신 그 복잡함을 효과적으로 상대할 수 있는 전략과 기법이 필요하다. +- 문제는 비지니스 로직의 복잡함을 효과적으로 다루기 위한 방법과 기술적인 복잡함을 효과적으로 처리하는 데 적용되는 방법이 다르다는 점이다. +- 따라서 두 가지 복잡함이 코드에 한데 어우러져 나타나는 전통적인 개발 방식에서는 효과적으로 복잡함을 다루기가 힘들다. +- 가장 먼저 할 일은 **성격이 다른 이 두 가지 복잡함을 분리**해내는 것이다. + +#### 😰 실패한 해결책 EJB +- 목표 : 개발자가 로우레벨의 기술적인 복잡함에 신경쓰지 않고 비즈니스 로직을 효과적으로 개발하는 데 더 집중할 수 있게 하자는 목표 +- 오히려 EJB라는 환경과 스펙에 종속되는 코드로 만들어져야 하는 부담을 안게 됨 +- 💥 오히려 더 큰 복잡함을 추가하는 실수를 범함!! +- 객체지향적인 특성을 잃어버린 밋밋한 서비스 스크립트성 코드로 변질됨. +- EJB의 발전주기는 너무 느려서 엔터프라이즈 개발 기술의 발전을 따라잡지 못함 + +#### 💚 비침투적인 방식을 통한 효과적인 해결책: 스프링 +- 목표 : 스프링은 EJB와 마찬가지로 기술적인 복잡함을 애플리케이션 핵심 로직에서 제거하는 데 목표 +- 스프링은 **비침투적인** 방식을 택했다. 기술적인 복잡함과 비즈니스 로직을 다루는 코드를 깔끔하게 분리할 수 있었다. +- 스프링 스스로가 애플리케이션 코드에 불필요하게 나타나지 않도록 하는 것이다. +- 결과 : 성공적이었다. 스프링을 통해 성격이 다른 복잡함들을 깔끔하게 분리해줬으므로 각각을 +효과적으로 상대할 수 있는 기반이 마련됐다. +> 🔑 **침투적인 기술**
+ EJB처럼 어떤 기술을 적용했을 때 그 기술과 관련된 코드나 규약 등이 코드에 등장하는 경우 + +> 🔑 **비침투적인 기술**
+ 기술의 적용 사실이 코드에 직접 반영되지 않는다는 특징이 있다. 어딘가에는 + 기술의 적용에 따라 필요한 작업을 해줘야 하겠지만 애플리케이션 코드 여기저기에 + 불쑥 등장하고나, 코드의 설계와 구현 방식을 제한하지는 않는다는 것이 특징이다! + +
+ +### 🍃 복잡함을 상대하는 스프링의 전략 +💡 비즈니스 로직을 담은 애플리케이션 코드와 엔터프라이즈 기술을 처리하는 코드를 분리시키는 것💡 + +#### 기술적 복잡함을 상대하는 전략 +1. 첫 번째 문제: 기술에 대한 접근 방식이 일관성이 없고, 특정 환경에 종속적이다. +- 일관성 없는 기술과 서버환경의 변화에 대한 스프링의 공략 방법은 바로 서비스 추상화이다. +- 추상화를 통해 로우레벨의 기술 구현 부분과 기술을 사용하는 인터페이스를 분리하고, 환경과 세부 기술에 독립적인 접근 인터페이스를 제공 +2. 두 번재 문제: 기술적인 처리를 담당하는 코드가 성격이 다른 코드에 섞여 등장한다. +- 기술과 비즈니스 로직의 혼재로 발생하는 복잡함을 해결하기 위한 스프링의 접근 방법은 바로 AOP다. +- AOP는 최후까지 애플리케이션 로직을 담당하는 코드에 남아 있는 기술 관련 코드를 깔끔하게 분리해서 별도의 모듈로 관리하게 해주는 강력한 기술이다. +- AOP를 적용하지 않았을 때는 기술과 비지니스 로직이 지저분하게 얽혀서 다루기 힘들다는 문제도 있지만, 기술적인 코드가 여기저기 중복돼서 나타난다는 것도 심각한 문제점이다. +- AOP는 기술을 다루는 코드로 인한 복잡함이 기술 그 자체 이상으로 불필요하게 증대되지 않도록 도와주는 가장 강력한 수단이다. + +#### 비즈니스와 애플리케이션 로직의 복잡함을 상대하는 전략 +- 비즈니스 로직을 다루는 핵심 코드에 오류가 있으면 치명적인 문제가 발생할 수 있다. +- 비즈니스 로직의 복잡함을 상대하는 전략은 자바라는 객체지향 기술 그 자체다. +- 스프링은 단지 객체지향 언어의 장점을 제대로 살리지 못하게 방해했던 요소를 제거하도록 도와줄 뿐이다. + +#### 핵심도구 : 객체지향과 DI +- 스프링의 모토는 결국 “기본으로 돌아가자”이다. +- 자바의 기본인 객체지향에 충실한 설계가 가능하도록 단순한 오브젝트로 개발할 수 있고, 객체지향의 설계 기법을 잘 적용할 수 있는 구조를 만들기 위해 DI 같은 유용한 기술을 편하게 적용하도록 도와주는 것이 스프링의 기본 전략이다. +- DI를 적용해서 오브젝트를 분리하고, 인터페이스를 도입하고, DI로 관계를 연결해줄 것이다. +- => DI는 좋은 오브젝트 설계의 결과물이기도 하지만 DI를 열심히 적용하다 보면 객체지향 설계의 원칙을 +잘 따르고 그 장점을 살린 설계가 나올 수도 있다. +- 모든 스프링의 기술과 전략은 객체지향이라는 자바 언어가 가진 강력한 도구를 극대화해서 사용할 수 있도록 돕는 것이라고 볼 수 있다. + +
+ +## 8.3 POJO 프로그래밍 +⭐스프링의 정수(essence)⭐ += 엔터프라이즈 서비스 기능을 POJO에 제공하는 것 + +분리됐지만 반드시 필요한 엔터프라이즈 서비스 기술을 POJO 방식으로 개발된 애플리케이션 핵심 로직을 담은 코드에 제공한다는 것이 스프링의 가장 강력한 특징과 목표다. + +### 🍃 스프링의 핵심: POJO +- 스프링 애플리케이션은 POJO를 이용해서 만든 애플리케이션 코드와, POJO가 어떻게 관계를 맺고 동작하는지를 정의해놓은 설계정보로 구분된다. +- 스프링의 주요 기술인 IoC/DI, AOP, PSA(Portable Service Abstraction)는 애플리케이션을 POJO로 개발할 수 있게 하는 가능기술(enabling technology)이라고 불린다. + +### 🍃 POJO란 무엇인가? +- POJO = Plain Old Java Object +- 자바의 단순한 오브젝트를 이용해 애플리케이션의 비즈니스 로직을 구현하는 것! + +### 🍃 POJO의 조건 +그저 EJB를 사용하지 않으면 POJO? +특정 프레임워크의 클래스를 상속하지 않으면 POJO? + +
+ +다음의 3가지 조건을 적어도 충족해야 POJO이다. +1. 특정 규약에 종속되지 않는다. +- POJO는 자바 언어와 꼭 필요한 API 외에는 종속되지 않아야 한다. +- 특정 규약을 따라 비즈니스 컴포넌트를 만들어야 하는 경우는 POJO가 아니다. +- 객체지향 설계의 자유로운 적용이 가능한 오브젝트여야만 POJO라고 불릴 수 있다. + +2. 특정 환경에 종속되지 않는다. +- 특정 환경에 종속적이어야만 동작하는 오브젝트도 POJO라고 할 수 없다. + +3. 객체지향적인 원리에 충실해야한다. + +### 🍃 POJO의 장점 +- 특정한 기술과 환경에 종속되지 않는 오브젝트는 그만큼 깔끔한 코드가 될 수 있다. +- 자동화된 테스트에 매우 유리하다. +- 객체지향적인 설계를 자유롭게 적용할 수 있다. + +### 🍃 POJO 프레임워크 +- POJO 프로그래밍이 가능하도록 기술적인 기반을 제공하는 프레임워크를 POJO 프레임워크라고 한다. +- EX. 스프링프레임워크와 하이버네이트를 대표적인 POJO 프레임워크로 꼽을 수 있다. +- 스프링은 비즈니스 로직의 복잡함과 엔터프라이즈 기술의 복잡함을 분리해서 구성할 수 있게 도와준다. +- 하지만 스프링은 기술영역에만 관여하지 비즈니스 로직을 담당하는 POJO에서는 모습을 감춘다. +- 스프링은 개발자들이 복잡한 엔터프라이즈 기술보다는 이러한 객체지향적인 설계와 개발의 원리에 좀 더 집중할 수 있도록 기회를 준다. + +
+ +## 8.4 스프링의 기술 +- 세 가지(IoC/DI, AOP, PSA) 가능기술(enabling technology)을 제공한다. +- 스프링의 기술들은 스프링 프레임워크가 만들어진 진정한 목표인 POJO 기반의 엔터프라이즈 개발을 편리하게 해주는 도구일 뿐이다. + +### 🍃 제어의 역전(IoC)/의존관계 주입(DI) +왜 두 개의 오브젝트를 분리해서 만들고, 인터페이스를 두고 느슨하게 연결한 뒤, 실제 사용할 대상은 DI를 통해 외부에서 지정하는 것일까? 이렇게 DI 방식으로 하는 것이 그렇지 않은 경우, 즉 직접 자신이 사용할 오브젝트를 new 키워드로 생성해서 사용하는 강한 결합을 쓰는 방법보다 나은 점은 무엇일까? +가장 간단한 답변은 ‘유연한 확장이 가능하게 하기 위해서’라고 할 수 있다. + +- **유연한 확장** 이라는 장점은 OCP의 확장에는 열려있다에 해당한다. +- DI는 역시 OCP의 변경에는 닫혀있다 라는 말로도 설명이 가능하다. + +#### DI의 활용 방법 +1. 핵심 기능의 변경 +- 의존하는 대상이 가진 핵심기능들을 di설정을 통해 변경하는 것 +2. 핵심 기능의 동적인 변경 +- 핵심기능을 런타임 시에 조건에 따라 다르게 처리할 수 있음. +- 기술적으로 보면 다이내믹 라우팅 프록시나 프록시 오브젝트 기법을 활용할 수 있음 +3. 부가기능의 추가 +- 핵심기능은 그대로 둔 채로 부가기능을 추가할 수 잇음. +- 부가 기능의 추가 방식을 특정 오브젝트가 아니라 좀 더 많은 대상으로 일반화해서 적용하면 AOP가 된다. +4. 인터페이스의 변경 +- 인터페이스를 정의해주고 di를 통해 어댑터 역할을 하는 오브젝트를 이용하게 해준다. +5. 프록시 +- 지연로딩에 프록시가 사용된다. +6. 템플릿과 콜백 +- 반복적으로 등장하지만 항상 고정적인 변하지 않는 작업 흐름과 그 사이에서 자주 바뀌는 부분을 분리해서 템플릿과 콜백으로 만들고 DI를 적용해 볼 수 있다. +- 템플릿은 한 번 만들어두면 콜백이 바뀌어도 재사용할 수 있다는 기능의 확장에도 변하지 않는다는 OCP의 폐쇄 원칙에도 잘 들어맞는다. +7. 싱글톤과 오브젝트 스코프 +- DI할 오브젝트의 생명주기를 컨테이너가 관리해 주기 때문에 편리하다. +- 전통적인 싱글톤 패턴은 오브젝트에 많은 제약을 가해서 만들어지기 때문에 컨테이너에서 생성하고 관리하는 싱글톤 빈은 매우 유용하다. +8. 테스트 +- 테스트를 위한 클라이언트 코드의 변경 없이 의존 오브젝트를 의도한 대로 자유롭게 제어해서 효과적으로 테스트를 진행할 수 있다. + +### 🍃 애스펙트 지향 프로그래밍(AOP) +POJO만으로 엔터프라이즈 애플리케이션을 개발하면서도 +엔터프라이즈 서비스를 선언적으로 제공하는 데 +반드시 필요한 것이 바로 이 AOP 기술이다. + +#### AOP의 적용기법 +1. 스프링과 같이다이내믹 프록시를 사용하는 방법 +2. AspectJ와 같이 자바 언어의 한계를 넘어 언어의 확장을 이용하는 방법 + +#### AOP의 적용 단계 +1. AOP 적용 1단계: 미리 준비된 AOP 이용 +- EX. 스프링이 직접 제공하는 대표적인 AOP인 트랜잭션 +- EX. @Configurable +2. AOP 적용 2단계: 전담팀을 통한 정책 AOP 이용 +- EX. 비즈니스 로직을 가진 오브젝트에 대한 보안, 특정 계층의 오브젝트 이용 전후의 작업 기록을 남기는 로깅, 데이터 추적을 위한 트레이싱, 특정 구간의 실시간 성능 모니터링 +3. AOP 적용 3단계: AOP의 자유로운 이용 +- 개발자가 스스로 AOP를 활용 + +### 🍃 포터블 서비스 추상화(PSA) +환경과 세부 기술의 변화에 관계없이 일관된 방식으로 기술에 접근할 수 있게 해주는 PSA += Portable Service Abstraction + +- 특정 환경과 기술에 종속적이지 않다는 게 +그런 기술을 사용하지 않는다는 뜻은 아니다. +- 다만 POJO 코드가 그런 기술에 직접 노출되어 만들어지지 않는다는 말이다. +- 서비스 추상화는 단지 구체적인 기술에 종속되지 않게 하기 위해서만 사용되는 건 아니다. +- 테스트가 어렵게 만들어진 API나 설정을 통해 주요 기능을 외부에서 제어하게 만들고 싶을 때도 이용할 수 있다.