스프링

스프링

2020. 5. 1. 19:15ㆍ인프런/스프링 입문

프레임 워크

프레임워크는 라이브러리와 달리 애플리케이션의 틀과 구조를 결정할 뿐 아니라, 그 위에 개발된 개발자의 코드를 제어한다. 프레임워크는 구체적이며 확장 가능한 기반 코드를 가지고 있으며, 설계자가 의도하는 여러 디자인 패턴의 집합으로 구성되어 있습니다.

스프링 프레임워크

스프링 프레임 워크란 자바 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크로서 간단히 스프링(Spring)이라고도 합니다. 동적인 웹 사이트를 개발하기 위한 여러 가지 서비스를 제공하고 있습니다. 대한민국 공공기관의 웹 서비스 개발 시 사용을 권장하고 있는 전자정부 표준프레임워크의 기반 기술로서 쓰이고 있습니다.

이번에는 메이븐과 이클립스를 사용하여 스프링에 대해 알아보겠습니다.

스프링 프레임워크의 특징

스프링은 다른 프레임워크에 비해 다음과 같은 특징이 있습니다.

경량 컨테이너로서 자바 객체를 직접 관리한다. 각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다.
스프링은 Plain Old Java Object 방식의 프레임워크이다. 일반적인 J2EE 프레임워크에 비해 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없어 기존에 존재하는 라이브러리 등을 지원하기에 용이하고 객체가 가볍다.
스프링은 제어 반전(IoC : Inversion of Control)을 지원한다. 컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다.
스프링은 의존성 주입(DI : Dependency Injection)을 지원한다. 각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜준다.
스프링은 관점 지향 프로그래밍(AOP : Aspect-Oriented Programming)을 지원한다. 따라서 트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있다.
스프링은 영속성과 관련된 다양한 서비스를 지원한다. iBATIS나 하이버네이트 등 이미 완성도가 높은 데이터베이스 처리 라이브러리와 연결할 수 있는 인터페이스를 제공한다.
스프링은 확장성이 높다. 스프링 프레임워크에 통합하기 위해 간단하게 기존 라이브러리를 감싸는 정도로 스프링에서 사용이 가능하기 때문에 수많은 라이브러리가 이미 스프링에서 지원되고 있고 스프링에서 사용되는 라이브러리를 별도로 분리하기도 용이하다.

메이븐

빌드

빌드란 소스코드 파일을 컴퓨터에서 실행할 수 있는 독립 소프트웨어 가공물로 변환하는 과정 또는 그에 대한 결과물입니다. 이를 좀 더 쉽게 말하자면 우리가 작성한 소스코드(java), 프로젝트에서 쓰인 각각의 파일 및 자원 등(. xml,. jpg,. jar,. properties)을 JVM이나 톰캣 같은 WAS가 인식할 수 있는 구조로 패키징 하는 과정 및 결과물이라고 할 수 있다.

빌드 도구

- 빌드 도구란 프로젝트 생성, 테스트 빌드, 배포 등의 작업을 위한 전용 프로그램입니다.
- 빠른 기간 동안 계속해서 늘어나는 라이브러리를 추가하고 프로젝트를 진행하며 라이브러리의 버전 동기화의 어려움을 해소하고자 등장하였습니다.
- 초기의 java 빌드 도구로 Ant를 많이 사용하였으나 최근 많은 빌드 도구들이 생겨나 Maven이 많이 쓰였고, 현재는 Gradle이 많이 쓰입니다.(Ant는 스크립트 작성도 많고, 라이브러리 의존 관리가 되지 않아 불편함)

정의 및 특징

Maven은 자바용 프로젝트 관리 도구로 Apache Ant의 대안으로 만들어졌으며 필요한 라이브러리를 특정 문서(pom.xml)에 정의해 놓으면 내가 사용할 라이브러리뿐만 아니라 해당 라이브러리가 작동하는 데에 필요한 다른 라이브러리들까지 관리하여 네트워크를 통해서 자동으로 다운로드하여 줍니다.

그리고 Maven은 중앙 저장소를 통한 자동 의존성 관리를 중앙 저장소(아파치 재단에서 운영 관리)는 라이브러리를 공유하는 파일 서버라고 볼 수 있고, 메이븐은 자기 회사만의 중앙 저장소를 구축할 수도 있습니다.

마지막으로 간단한 설정을 통한 배포 관리가 가능합니다.

Maven LifeCycle

LifeCycle

LifeCycle은 미리 정해진 빌드 순서
메이븐은 프레임워크이기 때문에 동작 방식이 정해져 있고, 미리 정의하고 있는 빌드 순서가 있다. 이를 라이프사이클(Lifecycle)이라 합니다.

Default(Build) : 일반적인 빌드 프로세스를 위한 모델입니다.
Clean : 빌드 시 생성되었던 파일들을 삭제하는 단계
Validate : 프로젝트가 올바른지 확인하고 필요한 모든 정보를 사용할 수 있는지 확인하는 단계
Compile : 프로젝트의 소스코드를 컴파일하는 단계
Test : 유닛(단위) 테스트를 수행하는 단계(테스트 실패 시 빌드 실패로 처리, 스킵 가능)
Pacakge : 실제 컴파일된 소스 코드와 리소스들을 jar, war 등등의 파일 등의 배포를 위한 패키지로 만드는 단계
Verify : 통합 테스트 결과에 대한 검사를 실행하여 품질 기준을 충족하는지 확인하는 단계
Install : 패키지를 로컬 저장소에 설치하는 단계
Site : 프로젝트 문서와 사이트 작성, 생성하는 단계
Deploy : 만들어진 package를 원격 저장소에 release 하는 단계

최종 빌드 순서는 compile => test => package입니다.

compile : src/main/java 디렉터리 아래의 모든 소스 코드가 컴파일됩니다.
test : src/test/java, src/test/resources 테스트 자원 복사 및 테스트 소스 코드 컴파일됩니다.
※ junit : 단위 테스트 프레임워크. 테스트 단계를 거치기 위해 의존 설정을 해줍니다.
packaging : 컴파일과 테스트가 완료된 후, jar, war 같은 형태로 압축하는 작업.

Phase(단계)

Build Lifecycle의 각각의 단계를 Phase라고 합니다.
Phase는 의존관계를 가지고 있어 해당 Phase가 수행되려면 이전 단계의 Phase가 모두 수행되어야 합니다.
즉, 모든 빌드 단계는 이전 단계가 성공적으로 실행되었을 때 실행된다는 것이 Dependency입니다.

Goal

특정 작업, 최소한의 실행 단위(task).
하나의 플러그인에서는 여러 작업을 수행할 수 있도록 지원하며, 플러그인에서 실행할 수 있는 각각의 기능(명령)을 Goal이라고 한다.(각각의 Phase에 연계된 Goal을 실행하는 과정을 Build라고 한다.)

플러그인의 goal을 실행하는 방법은 다음과 같습니다.

- mvn groupId:artifactId:version:goal(아래와 같이 생략 가능)
- mvn plugin:goal

Maven 설정 파일

settings.xml

메이븐 빌드 툴과 관련한 설정 파일
MAVEN_HOME/conf 디렉터리에 위치 (메이븐 설치 시 기본 제공)
settings.xml의 설정

** 메이븐을 빌드할 때 의존 관계에 있는 라이브러리, 플러그인을 중앙 저장소에서 개발자 PC로 다운로드하는 위치(로컬 저장소)의 기본 설정 'USER_HOME/. m2/repository'인데 settings.xml의 에 원하는 로컬 저장소의 경로를 지정, 변경할 수 있습니다.

2) POM(프로젝트 객체 모델(Project Object Model))

POM은 pom.xml파일을 말하며 pom.xml은 메이븐을 이용하는 프로젝트의 root에 존재하는 xml 파일입니다.(하나의 자바 프로젝트에 빌드 툴을 maven으로 설정하면, 프로젝트 최상위 디렉터리에 "pom.xml"이라는 파일이 생성된다.)
Maven의 기능을 이용하기 위해서 POM이 사용된다. 그리고 파일은 프로젝트마다 1개이며, pom.xml만 보면 프로젝트의 모든 설정, 의존성 등을 알 수 있으며 다른 파일 이름으로 지정할 수도 있다. (mvn -f 파일명. xml test). 하지만 pom.xml으로 사용하기를 권장한다.

엘리먼트

modelVersion : POM model의 버전
parent : 프로젝트의 계층 정보
groupId : 프로젝트를 생성하는 조직의 고유 아이디를 결정한다. 일반적으로 도메인 이름을 거꾸로 적는다.
artifactId : 프로젝트 빌듯이 파일 대표이름 이다. groupId 내에서 유일해야 한다. Maven을 이용하여 빌드시 다음과 같은 규칙으로 파일이 생성된다.
artifactid-version.packaging. 위 예의 경우 빌드할 경우 bo-0.0.1-SNAPSHOT.war 파일이 생성된다. (하단 예시 파일 참고)
version : 프로젝트의 현재 버전, 프로젝트 개발 중일 때는 SNAPSHOT을 접미사로 사용.
packaging : 패키징 유형(jar, war, ear 등)
name : 프로젝트, 프로젝트 이름
description : 프로젝트에 대한 간략한 설명
url : 프로젝트에 대한 참고 Reference 사이트
properties : 버전 관리 시 용이하다. ex) 하당 자바 버전을 선언하고 dependencies에서 다음과 같이 활용 가능하다. <version>${java.version}</version><version>${java.version}</version>
dependencies : dependencies태그 안에는 프로젝트와 의존 관계에 있는 라이브러리들을 관리한다.
build : 빌드에 사용할 플러그인 목록