[Spring] 스프링의 역사 이야기

초기 자바 기술의 정파 기술 EJB 이 보편적으로 금융권에서 사용되고 있었다. ( 유일무이 ) 

EJB의 문제점

• 정말 어렵고 느리다. 
• 인터페이스 다 구현해야 하고 복잡하다.
• EJB에 의존적이다.
• 비싸다 ( 수천만원)

위 문제점들로 인해 두 명의 개발자가 직접 만들게 되는데...  아래 두 가지다.

•  로드 존슨 : (Rod Johnson) -> (Spring framework)
•  개빈 킹 : ( Gavin King ) - > (하이버네이트) - > (JPA)
  -> JPA (자바 표준 기술)가 자바의 ORM시장을 거의 다 장악하고 있고 구현체로는 하이버네이트가 80% 이상 차지하고 있다. 

 

표준 인터페이스

• JPA (하이버 네이트를 정제해서 표준화시킨 것) 

 

JPA 구현체

• 하이버 네이트 (실무 개발자가 만든 것)
• 기타
• Eclipse

---

스프링의 역사 (전설)

• 2002년 로드 존슨이 책 출간
• EJB의 문제점 지적
• 고품질의 확장 가능한 애플리케이션을 개발할 수 있다. 그리고 30,000라인의  이상의 기반 기술을 예제 코드로 선보임
• 여기에 스프링 핵심 개념과 기반 코드가 들어있다. 
• 개발자들이 책의 예제 코드를 가져다 사용할 정도로 열광함  ( 좋았나 봄 )
• BeanFactory, ApplicationContext, POJO, 제어의 역전, 의존관계 주입 등
• Juergen Hoeller(유겐 휠러), Yann Caroff(얀 카로프)가 로드 존슨에게 오픈 소스 프로젝트 제안
• 스프링의 핵심 코드의 상당수는 유겐 휠러가 지금도 개발 중
• 스프링 이름은 새로운 시작이라는 뜻으로 (Spring) 지어짐

 

 스프링 이란!? 

필수 

• 스프링 프레임워크 : 핵심 기능
• 스프링 부트 : 여러 스프링 기술을 사용을 편리하게 해주는 기능

선택

• 스프링 데이터 : CRUD ( 편하게 도와줌 )
• 스프링 세션 : 세션 기능을 편리하게 사용
• 스프링 시큐리티 : 보안 관련
• 스프링 Rest Docs : API문서와 테스트를 묶어서 편리하게 해 줌
• 스프링 배치 : 조금씩 가져다 처리
• 스프링 클라우드 : 클라우드 기술에 특화

 

스프링 프레임 워크

• 핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타
• 웹 기술 : 스프링 MVC, 스프링 WebFlux
• 데이터 접근 기술 : 트랜잭션, JDBC, ORM 지원, XML 지원
• 기술 통합 : 캐시, 이메일, 원격 접근, 스케줄링
• 테스트 : 스프링 기반 테스트 지원
• 언어 : 코틀린, 그루비
• 최근에는 스프링 부트를 통해 프레임워크 기술들을 편리하게 사용하고 있다.

 

스프링 부트 ( 스프링 프레임 워크를 편리하게 사용하는 기능 제공용 ) 

• 스프링을 편리하게 사용하도록 지원, 최근에는 Default 값으로 사용
• 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
• Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨
• 손쉬운 빌드 구성을 위한 starter 종속성 제공
• 스프링과 3rd parth(외부) 라이브러리 자동 구성
• 메트릭(모니터링), 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
• 관례에 의한 간결한 설정

 

스프링 단어!?

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

 

스프링 만든 이유!? 

핵심 개념! 

• 자바 언어 기반의 프레임 워크 ( 객체 지향 언어 )
• 객체 지향 언어가 가장 특징을 살려내는 프레임 워크 
• 따라서 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와준다. 

 

 

운전자 -- 자동차 -- (K3, 아반떼 , K8) 운전자와 무관하게 자동차 세상을 무한히 확장 가능하며, 클라이언트에 영향을 주지 않고 추가적인 구현이 가능하다. 역할과 구현으로 구분하면 세상이 단순해지고 유연해진다. 

• (운전자) 클라이언트는 (자동차) 인터페이스만 알면 된다
• (운전자) 클라이언트는 (K3) 내부 구조를 몰라도 된다.
• (운전자) 클라이언트는 (K3) 내부 구조가 변경되어도 영향받지 않는다. 
• (운전자) 클라이언트는 (K3) 구현 대상 자체가 변경돼도 영향받지 않는다.

역할 = 인터페이스 (자동차)
구현  = 인터페이스를 구현한 클래스, 구현 객체 (K3)

객체를 설계할 때 역할과 구현을 명확하게 분리한다.

객체 설계 시 역할을 먼저 부여하고 그 역할을 수행하는 구현 객체 만들기!! 인 터 페 이 스 먼 저!!인터페이스를 안정적으로 잘 설계해야 한다. 인터페이스가 변하면 클라이언트 서버 모두가 변한다. 

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

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

다형성의 본질은 클라이언트를 변경시키지 않고, 서버의 구현 기능을 유연하게 변경할 수 있는 것이다. 

객체지향에서는 다형성이 가장 가장 중요하다!! (스프링은 다형성을 극대화 )

• 스프링에서의 제어의 역전, 의존관계 주입은 다형성을 활용한 역할과 구현을 편리하도록 지원한다.
• 스프링을 사용하면 마치 레고 블록 조립하듯이 공연 무대의 배우를 선택하듯이 구현을 편리하게 변경할 수 있다.