INTRO
몇몇 컨셉이나, 프로그래밍을 통해 몇가지 개발을 진행해 본적은 있다.
다만, 최근의 방향, 부가적인 컴포넌트들, 핵심이 되는 컨셉등을 알아가기에는 조금 힘든감이 있어, 조금씩 공부해보기로 했다.
선택한 책은 다음과 같다.
제목 | 링크 |
토비의 스프링 | www.yes24.com/Product/Goods/7516911 |
실전! 스프링 5와 Vue.js 2로 시작하는 모던 웹 애플리케이션 개발 | http://www.yes24.com/Product/Goods/86038744 |
사실 몇가지 책이 더 있지만, 그건 그 때가서 보도록 하겠다.
기본적으로, Spring 만 공부할 것은 아니라, Javascript나 Vue에 대한 내용도 포함해서 공부할 예정이라, 해당 내용도 추가로 따로 작성할 예정이다.
Spring의 정의
Spring은 우선 자바 엔터프라이즈(JAVA EE) 애플리케이션 개발에 사용되는 프레임워크다.
스프링은 크게 틀 / 공통 프로그래밍 모델 / 기술 API 를 제공한다.
틀
스프링 컨테이너 / 애플리케이션 컨텍스트라고 불리는 스프링 런타임 엔진을 제공한다.
컨테이너가 설정 정보를 참고하여 애플리케이션을 구성하는 오브젝트를 생성/관리하게 된다.
즉, 우리가 설정 정보를 작성하게 되면, 스프링 런타임 엔진이 그 것에 해당하는 오브젝트를 생성/관리하게 된다는 것이다.
공통 프로그래밍 모델
애플리케이션 코드가 어떻게 작성되어야 하는가에 대한 기준을 제시한다.
- IoC/DI
- 오브젝트 생명주기/의존관계에 대한 프로그래밍 모델
- 스프링이 직접 제공하는 기술과 API, 컨테이너도 IoC/DI 방식으로 작성되어 있음
- 서비스 추상화
- 환경/서버, 특정 기술에 종속되지 않고 이식성이 뛰어나며 유연하게 애플리케이션을 만들 수 있게 하는 것
- AOP
- 애플리케이션 코드에 산재해서 나타나는 부가적인 기능들을 독립적으로 모듈화하는 프로그래밍 모델
- 다양한 엔터프라이즈 서비스를 적용하면서, 깔끔한 코드를 유지할 수 있게 도움을 줌
기술 API
- 개발의 다양한 영역에 바로 활용할 수 있는 방대한 양의 기술API를 제공한다.
- UI 작성, 웹 프레젠테이션 계층, 비즈니스 서비스 계층, 기반 서비스 계층, 도메인 계층, 데이터 엑세스 계층 등에서 필요한 주요 기술을 일관성있게 사용할 수 있게 지원해주는 기능 및 전략 클래스를 제공한다.
- 모든 기술은 JavaEE 기반이다.
사실 토비의 스프링을 보면, 한단계씩 발전시키며 하나하나 어떤 기술이 들어가는지, Spring 프레임워크를 만드는 수준으로 진행하게 된다.
다만, 그렇게 자세하게 적지는 않고 그 컨셉만 가져오며 조금씩 정리하겠다.
제어의 역전(IoC) / 의존성 주입(DI)
BEAN(빈)은 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트다.
다른 말로, 스프링 규약에 의해 스프링 컨테이너가 관리하는 객체라고도 한다.
이 BEAN(빈)의 생성과 관계설정과 같은 제어를 담당하는 것이 빈 팩토리(Bean Factory) 이고, 이를 좀 더 확장한 애플리케이션 컨텍스트(Application Context)를 사용한다.
자바에서는 객체의 의존성을 관리하기 위한 두 가지 방법이 있다.
- 객체가 직접 의존 관계에 있는 객체들의 생성자를 호출(EX> 생성자 내에서)하는 것으로 의존성을 인스턴스화 하는 것.
- 룩업(LOOK-UP) 패턴을 활용해 의존성들을 찾아 배치하는 것
먼저 첫번째부터 보자.
public class RegistrationService {
private MailSender mailSender;
public RegistrationService() {
// 의존하는 객체를 인스턴스화
this.mailSender = new MailSender();
}
// 나머지 로직
}
MailSender를 인스턴스화 하여 의존성을 관리하려고 하고 있다.
두번째 예시는 생성자 혹은 Setter를 통해 의존성을 관리한다.
public class RegistrationService {
private MailSender mailSender;
public RegistrationService(MailSender mailSender) {
this.mailSender = mailSender;
}
// 나머지 로직
}
생성자의 인자로 MailSender 인스턴스를 추가한다.
다만, RegistrationService는 의존성을 제어하지 못한다. 스프링이 MailSender 인스턴스를 인스턴스화 하는 책임을 가지게 된다. 이런 상황에서 제어의 역전 (Inversion of Control, IoC) 가 유래되었다.
위 상황을 정리하면 다음과 같다.
- 프로그램의 제어 흐름 구조가 뒤바뀌는 것
- 자신이 사용할 오브젝트를 선택하거나 생성하지 않는다.
- 자신도 어떻게 만들어지고 어디서 사용되는지 알 수 없다.
- 엔트리 포인트인 main()과 같은 경우를 제외하고, 모든 오브젝트는 위임받은 제어 권한을 갖는 특별한 오브젝트에 의해 결정되고 만들어진다.
- 라이브러리/프레임워크
- 라이브러리 : 애플리케이션 흐름을 직접 제어, 동작 중 필요한 기능이 있을 때 능동적으로 라이브러리를 사용
- 프레임워크 : 애플리케이션 코드가 프레임워크에 사용됨.
스프링은 우리가 전달하는 설정 메타 데이터를 통해, 클래스에 어떤 의존성이 있는지 파악한다.
전통적인 방법은 applicationContext.xml 이라고 하는 XML 파일에 설정 메타 데이터를 넣는다.
스프링 2.5부터는 컨테이너를 구동하는 데 어노테이션 기반의 설정을 사용할 수 있다.
그리고 스프링 3.0부터는 XML 설정 없이 자바 기반의 설정을 사용할 수 있다. (보통 최근에는 XML 기반의 설정은 구식으로 간주되 레거시 코드에서 사용된다.)
스프링 컨테이너
스프링에서 org.springframework.context.ApplicationContext 인터페이스는 IoC 컨테이너 (애플리케이션 컨테이너)를 의미한다.
독립적으로 실행되는 애플리케이션에서 컨테이너를 설정하는 일반적인 방법은 ClassPathXmlApplicationContext 또는 AnnotationConfigApplicationContext를 사용하는 것이다.
둘다 ApplicationContext의 구현체이다.
의존관계 주입(DI)
스프링 IoC의 대표적인 동작원리이며, 주로 의존관계 주입이라고 불린다.
오브젝트 레퍼런스를 외부로부터 제공(주입)받고 이를 통해 다른 오브젝트와 다이내믹하게 의존관계가 만들어지는 게 핵심이다.
설계 시점과 코드에는 클래스와 인터페이스 사이의 느슨한 의존관계만 만들어놓고, 런타임시에 실제 사용할 구체적인 의존 오브젝트를 제3자(DI 컨테이너)의 도움으로 주입받아, 다이내믹한 의존관게를 갖게 해주는 IoC의 특별한 케이스라고도 할 수 있다.
의존 관계 주입의 방법에는 생성자를 이용하거나, Setter를 이용할 수 있다.
아래는 프로젝트 설정 전에 빌드/관리 도구에 대한 설명이다.
다음 포스팅에는 어노테이션 부터 알아보도록 하자.
Maven / Gradle
Maven
- 주로 java에서 사용되는 프로젝트 빌드, 관리에 사용되는 도구이다.
- 프로젝트 전체적인 라이프 사이클을 관리하는 도구이면서, 필요한 라이브러리를 특정 문서(pom.xml : Project Object Model) 에 정의해두면 사용할 라이브러리 뿐 아니라, Dependency를 자동으로 해소해준다.
- 중앙 저장소(라이브러리 공유 파일 서버: Apache에서 운영/관리)를 통해 자동 의존성 관리를 할 수 있다.
- 간단한 설정을 통해 배포관리가 가능
LifeCycle
메이븐 자체가 프레임워크이므로, 동작 방식이 정해져 있고, 미리 정의하고 있는 빌드 순서가 있다.
- Default(Build) : 일반적인 빌드 프로세스를 위한 모델
- Clean : 빌드 시 생성되었던 파일들을 삭제
- Validate : 프로젝트가 올바른지 확인하고 필요한 모든 정보를 사용할 수 있는지 확인하는 단계
- Compile : 프로젝트의 소스코드를 컴파일 하는 단계
- Test : 유닛(단위) 테스트를 수행하는 단계 (테스트 실패 시, 발드 실패로 처리, 스킵 가능)
- Package : 실제 컴파일된 소스 코드와 리소스들을 jar, war 등등의 파일 등의 배포를 위한 패키지로 만드는 단계
- Verify : 통합 테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는 단계
- Install : 패키지를 로컬 저장소에 설치하는 단계
- Site : 프로젝트 문서와 사이트 작성, 생성하는 단계
- Deploy : 만들어진 package를 원격 저장소에 release하는 단계
최종 빌드 순서는 compile > test > package 이다.
- compile : src/main/java 디렉토리 아래의 모든 소스 코드가 컴파일
- test : src/test/java, src/test/resources 테스트 자원 복사 및 테스트 소스 코드가 컴파일 된다.
- package : 컴파일과 테스트가 완료 된 후, jar, war 같은 형태로 압축
Phase / Goal
Phase는 Maven의 Build LifeCycle의 각 단계를 말한다. 각각의 Phase는 의존관계를 가지고 있어 해당 Phase가 수행되려면 이전 단계의 Phase가 모두 수행되어야 한다.
하나의 플러그인에서는 여러 작업을 수행할 수 있도록 지원하며, 플러그인에서 실행할 수 있는 각각의 기능(명령)을 Goal이라고 한다. (최소한의 작업 단위(Task))
Gradle
프로젝트를 위한 범용 빌드 도구(Build Tool)이다.
간결함, 멀티 프로젝트 적용에 유리한 의존관계 설정, 상속을 활용한 멀티 모듈 구현 등의 장점을 가지고, Maven에 비해 매우 빠르다.
[참고 : https://goddaehee.tistory.com/199 ]
[참고 : https://bkim.tistory.com/13 ]
'Framework > Spring' 카테고리의 다른 글
[Spring] 스프링의 DI가 뭘까? (0) | 2022.07.26 |
---|---|
[Spring] 스프링의 Bean을 어떻게 쓸 수 있을까? (0) | 2022.07.23 |
[Spring] 스프링의 IoC Container가 뭘까? (0) | 2022.07.23 |
[Spring] 스프링 프레임워크가 뭘까? (0) | 2022.07.22 |
Spring Framework 아주 조금만 알아보자 - SpringMVC (0) | 2020.12.01 |