📗 스프링 프로젝트 시작하기
스프링을 이용해 애플리케이션 프로젝트를 처음 구성할 때 알아야할 기본적인 내용을 알아볼 것이다. (간단하게 작성 후 지나갈 것! 자세한 내용은 책 참고)
📖 자바 엔터프라이즈 플랫폼과 스프링 애플리케이션
📝 클라이언트와 백엔드 시스템
엔터프라이즈 애플리케이션은 자신이 클라이언트가 되어 다른 엔터프라이즈 시스템에 서비스를 요청할 수 있고, 엔터프라이즈 정보 시스템(EIS)이라고 불리는 백엔드 시스템의 기능을 이용해 동작하기도 한다
📝 애플리케이션 서버
스프링의 표준 플랫폼인 JavaEE 표준을 따르는 애플리케이션 서버를 알아보자
- 경량급 WAS/서블릿 컨테이너
- 기본적으로 톰캣(Tomcat)이나 제티(Jetty)같은 가벼운 서블릿 컨테이너만 있어도 충분
-EJB,리소스커넥터,WAS가 제공하는 분산 서비스 등이 굳이 필요하지 않다면 컨테이너 만으로도 핵심기능 모두 이용가능- WAS
- 고도의 안정성을 가짐
- 여러 대의 서버를 동시에 운영할 때 유리한 점이 많음
자바 엔터프라이즈 버전(JavaEE) 표준 최대한 활용가능
- 고가이며 무겁고 성능이 대단히 낫지는 않음.
◼ 스프링소스 tcServer
스프링소스는 톰캣을 기반으로 스프링에 최적화된 경량급 애플리케이션 서버인 tcServer를 개발
- 톰캣에서 사용하지 못하던 고급 서버 관리 기능, 배포 기능, 진단 기능 사용가능
📝 스프링 애플리케이션의 배포 단위
스프링이 만든 애플리케이션은 다음 세 가지의 단위로 배포가능
- 독립 웹 모듈
- 보통 war로 패키징된 독립 웹 모듈로 배포 서블릿 컨테이너를 쓴다면 유일한 방법
- 엔터프라이즈 애플리케이션
- 경우에 따라 확장자가 ear인 엔터프라이즈 애플리케이션으로 패키징하여 배포
- EJB모듈을 긴밀하게 사용하거나, EJB모듈에서 애플리케이션을 이용하는 경우- 백그라운드 서비스 모듈
- UI를 가질 필요가 없고, 백그라운드 서비스처럼 동작할 필요가 있다면 rar모듈로 만들어 배포 가능
📖 개발도구와 환경
📝 JavaSE와 JavaEE
◼ JavaSE/JDK
스프링 3.0의 기능을 사용하기 위해서는 JDK 5.0이상 버전으로 업그레이드 해야함
◼ JavaEE/J2EE
스프링 3.0이 사용될 플랫폼으로는 J2EE 1.4버전이나 JavaEE 5.0이 필요
📝 IDE
자바 5 이상을 지원하는 자바 개발도구 + 스키마를 지원하는 XML 편집기
(+ ANT, Maven과 같은 빌드 툴, 톰캣이나 자바 서버)
📝 STS(SpringSource Tool Suite)
스프링소스가 직접 만들어 제공하는 이클립스의 확장판
◼ SpringIDE 플러그인
스프링 개발에 유용한 기능을 제공하는 플러그인의 모음
- 스프링 프로젝트, 설정파일 생성 위저드, XML설정파일 에디터, 빈의 의존관계 그래프, 네임스페이스 관리 기능 등 편리한 기능, 도구 제공
▪ 빈 클래스 이름 자동완성
bean 태그의 class 애트리뷰트(속성)을 입력할 때 클래스 이름에 대한 자동완성 지원
▪ 빈 설정 오류 검증 기능
실시간으로 컴파일 오류 분석. 오류마크를 보여주어 문제가 있음을 확인시켜줌
▪ 프로젝트 생성, 설정파일 생성, 빈 등록 위저드
스프링 프로젝트 생성을 위한 스프링 프로젝트 위저드 사용가능
▪ 빈 의존관계 그래프
SpringIDE가 XML설정파일을 읽어서 자동으로 그래프를 그려줌
▪ AOP 적용 대상 표시
XML편집기를 이용할 때, 포인트 컷을 선언한 부분에 마크로 표시해줌
◼ STS 플러그인
STS에 더해서 스프링 애플리케이션의 서버 배치와 같은 추가기능
◼ 기타 플러그인
▪ M2Eclipse
Maven을 지원하는 이클립스 플러그인
▪ AJDT
이클립스에서 AspectJ를 지원하는 툴
▪ VMCI
Viretual Machtine Core Intergretion
- VMWare 배치기능에 주로 사용되기 위해 추가된 것
📝 라이브러리 관리와 빌드 툴
이제 애플리케이션 프로젝트를 IDE에 구성할 차례다
◼ 라이브러리 관리의 어려움
라이브러리를 여러 개 사용하는데, 버전이 라이브러리마다 여러 개이다.
- 버전이 각각의 라이브러리끼리 맞지않다면 오류 발생 - 동시에 다른 버전이 필요
=> 이 문제를 해결하는 가장 간단한 방법은 재패키징(repackaging)이다.
◼ 라이브러리 선정
라이브러리 선정 시 가장 먼저 해야할 것은 애플리케이션에서 정확히 어떤 기능이 필요한지를 정리하는 것이다.
▪ 스프링 모듈
스프링과 모듈 사이에 의존관계가 존재
- 필수 의존모듈과 선택 의존모듈을 구분해서 선점
▪ 라이브러리
오픈소스 라이브러리 또는 표준 API를 필요로 하기도 하고 때에따라 상용 제품의 라이브러리에 의존하기도 한다.
- 라이브러리의 종류와 특징을 살펴보고 적절한 라이브러리를 선택한다
- 애매한 경우는 어쩔 수 없이 시행착오를 거쳐야한다.
◼ 빌드 툴과 라이브러리 관리
자바의 대표적인 빌드 툴로는 Maven, ANT가 있다.
◼ 스프링 모듈의 두 가지 이름과 레포지토리
스프링 모듈 jar 파일의 이름을 살펴보면 다음과 같이 두가지 종류가 존재
spring-core-3.0.7.RELEASE.jar //Maven 명명 규칙 org.springframework.core-3.0.7.RELEASE.jar //OSGi 모듈 명명 규칙두 파일은 동일한 파일. 배포되는 기술에 따라 관례적으로 다른 이름 사용
- 스프링의 모든 모듈은 OSGi 호환. OSGi 스타일 모듈 이름 사용 권장
- OSGi 호환 스프링 모듈 사용하는 경우 Maven의 표준 레포지토리 대신 스프링소스가 제공하는 엔터프라이즈 번들 레포지토리 사용
📖 애플리케이션 아키텍처
📝 계층형 아키텍처
책임과 성격이 다른 것을 크게 그룹으로 만들어 분리해두는 것
- 티어 아키텍처라고도 한다
- 웹 기반의 엔터프라이즈 애플리케이션은 일반적으로 세 개의 계층을 가지므로 3계층 애플리케이션이라고도 한다.
◼ 아키텍처와 SoC
지금까지 해온 DI기반 설계와 구현전략을 아키텍처에서도 사용가능하다
(두 관심이 다른 오브젝트 분리-> 인터페이스를 사이에 둠-> DI컨테이너를 통해 관계를 맺어줌)
◼ 3계층 아키텍처와 수직 계층
데이터 액세스 계층, 서비스 계층, 프레젠테이션 계층으로 구분된다.
▪ 데이터 액세스 계층
DAO 계층이라고도 불림. - DAO 패턴을 보편적으로 사용하기 때문
- EIS 계층이라고도 한다.
-- ERP, 레거시 시스템, 메인프레임 등에 접근하는 역할을 하여서
데이터 액세스 계층은 다시 세분화된 계층으로 구분가능
(추상화 수준에 따른 구분이기 때문에 수직적인 계층이라고 부르기도 함)
▪ 서비스 계층
이상적인 POJO로 작성됨. 특별한 경우가 아니라면 추상화 수직 계층구조를 가질 필요가 없음.
- 서비스 계층과 기반 서비스 계층, DAO 계층 관계
(기반 서비스 계층이 3계층 어디에서나 접근 가능한 구조로 설정)
윈칙적으로 서비스 계층 코드가 기반 서비스 계층의 구현에 종속되면 안된다.
- 서비스 계층은 추상화된 인터페이스를 이용해 접근하도록 만들어야 함.
- 이상적인 서비스 계층은 백엔드 시스템가 연결되는 데이터 액세스 계층이 바뀌고, 클라이언트와 연결되는 프레젠테이션 계층이 모두 바뀌어도 그대로 유지될 수 있어야 한다.
▪ 프레젠테이션 계층
가장 복잡한 계층. 매우 다양한 기술과 프레임워크의 조합을 가질 수 있음.
HTTP 프로토콜을 사용하는 서블릿이 바탕.
다른 계층과 달리 클라이언트까지 범위가 확장될 수도 있다.
- 최근에는 점점 더 많은 로직이 클라이언트로 이동. (RIA, SOFEA)
◼ 계층형 아키텍처 설계의 원칙
- 각 계층은 응집도가 높으면서 다른 계층과는 낮은 결합도를 유지할 수 있어야 한다.
- 각 계층은 자신의 책임에만 충실해야 한다.
- 계층의 경계를 넘어갈 때는 반드시 특정 계층에 종속되지 않는 오브젝트 형태로 변환
📝 애플리케이션 정보 아키텍처
엔터프라이즈 애플리케이션은 사용자의 요청을 처리하는 동안만 간단한 상태를 유지
- 애플리케이션을 사이에 두고 흘러다니는 정보를 어떤식으로 다룰지에 따라 아키텍처 결정가능
- 데이터 중심 구조
-엔터프라이즈 애플리케이션에 존재하는 정보를 데이터로 다루는 경우- 오브젝트 중심 구조
-엔터프라이즈 애플리케이션에 존재하는 정보를 오브젝트로 다루는 경우
◼ DB/SQL 중심의 로직 구현 방식
하나의 업무 트랜잭션에 모든 계층의 코드가 종속되는 경향이 있음
- 하나의 단위 업무를 위해서만 존재하는 각 계층의 코드가 만들어짐
- 처음 만들 때 기준으로 개발이 쉽다는 장점
- 변화에 매우 취약하다는 단점
◼ 거대한 서비스 계층 방식
데이터 중심 구조의 단점을 피하면서 애플리케이션 코드의 비중을 높이는 방법
- 저장 프로시저의 사용을 자제하고 복잡한 SQL을 피하며, 주요로직은 서비스 계층의 코드에서 처리하도록 만드는 것
- 애플리케이션 코드에 비즈니스 로직이 담겨있어 자바 언어의 장점을 활용해 로직 구현이 가능하고 테스트도 수월하다.
- DAO가 다루는 SQL이 복잡하지 않다.
- 일부 DAO 코드는 여러 비즈니스 로직에서 공유해서 사용 가능하다.
- 프레젠테이션 계층의 뷰와 1:1로 매핑되지 않아도 되기 때문에- 데이터 액세스 계층의 SQL은 필요에 따라 만들어지기 쉬움
- 여전히 계층 간 결합도가 크다.- 크기가 큰 업무 트랜잭션 단위로 서비스 계층의 메소드가 생성됨
- 비슷한 기능의 코드가 중복되어 나타남
📝 오브젝트 중심 아키텍처
앞서 살펴본 데이터 중심 아키텍처와 가장 차이점?
- 도메인 모델을 반영하는 오브젝트 구조를 만들어두고 그것을 각 계층 사이에서 정보를 전송하는데 사용한다.
- 객체지향 분석과 모델링의 결과로 나오는 도메인 모델을 오브젝트 모델로 활용
- 데이터 중심 구조는 SQL실행결과를 맵에 저장 후, 서비스 계층에 전달하면 서비스 계층은 맵의 정보를 알아야 원하는 값을 추출해낼 수 있음.
- 모든 계층이 의존적- 오브젝트 중심 구조는 전 계층에 일관된 형식으로 존재할 수 있으므로, 각 계층이 원하는 정보가 어디 있는지 알고 있음.
- 각 계층이 의존적이지 않음
◼ 장점
- 간단히 오브젝트를 만들면 원하는 값을 추출해낼 수 있음
- 재사용이 가능해 코드의 중복이 일어나지 않아도 된다.
- 테스트를 할 때에도 값을 쉽게 검증할 수 있다.
◼ 문제점
- 성능면에서 약간의 손해를 감수해야 할 수도 있다.
- 모든 값이 고르게 사용되지 않는 경우, 그 값의 메모리와 전달시간 만큼의 손해- 오브젝트 관계에도 문제가 존재
- 필요하지 않은 오브젝트까지 함께 만들어 가져오는 경우, 상당한 낭비
◼ 해결책
- 지연된 로딩
- 최소한의 오브젝트 정보만 읽어두고, 관계하고 있는 오브젝트가 필요한 경우에만 다이나믹하게 DB에서 다시 읽어오는 것이 가능
- 약하긴 하지만 계층 사이의 결합이 발생- JPA나 JDO, 하이버네이트, TopLinK와 같은 오브젝트/RDB매핑 기술을 사용
- 기본적으로 지연된 로딩 기법을 제공
- 복잡한 DAO 코드를 만들지 않아도 된다.
🔷 빈약한 도메인 오브젝트 방식
도메인 오브젝트에 정보만 담겨있고, 정보를 활용하는 아무런 기능도 갖고 있지 않은 오브젝트
- 도메인 오브젝트를 전혀 사용하지 않는 것보다는 나음.
- 서비스 계층의 메소드에 대부분의 비즈니스 로직이 들어있음
- 재사용성이 떨어지고 중복의 문제가 발생하기 쉽다.
🔷 풍성한(영리한) 도메인 오브젝트 방식
빈약한 도메인 오브젝트의 단점을 극복하고 도메인 오브젝트의 객체지향적인 특징을 잘 사용할 수 있도록 개선한 것
- 특정 도메인 오브젝트나 그 관련 오브젝트가 가진 정보와 관계가 깊은 비즈니스 로직을 도메인 오브젝트에 넣어, 서비스 계층의 비즈니스 로직에서 재사용
public class Category {
...
List<Product> products;
public int calcTotalOfProductPrice() { //Category를 따로 받지 않고 자신이 직접 사용
int sum = 0;
for(Product prd : this.products()) { // 오브젝트가 가진 내부정보를 활용
sum += prd.getPrice();
}
return sum;
}
}▪ 장점
- 응집도가 높아진다
- 번거롭게 매번 호출을 할 필요가 없어짐- 코드의 중복이 없어진다
- 비슷한 코드를 여러 번 적을 필요가 없어짐
▪ 단점
- 도메인 오브젝트는 DI 받을 수 없다.
- 필요할 때마다 만들어지므로 스프링의 빈이 아님.
- DAO나 서비스 오브젝트 같은 스프링의 빈의 기능을 사용할 수 없음
🔷 도메인 계층 방식
지금까지 살펴본 바로는 도메인 모델을 따르는 오브젝트를 만들고 이를 활용하는 방법에는 한계가 존재
- 부가적인 작업이 필요
도메인 오브젝트가 스스로 필요한 정보는 DAO를 통해 얻고, 생성 또는 변경이 일어나면 DAO에게 변경사항을 반영해달라고 요청, DI를 받아서 기존 3계층의 오브젝트를 사용할 수는 없을까?
=> 도메인 오브젝트를 3계층과 같은 레벨로 격상시켜 하나의 계층을 이루도록 함
▪ 특성
- 도메인에 종속적인 비즈니스 로직의 처리는 도메인 계층의 오브젝트 안에서 진행
- 어디서 도메인 오브젝트를 만들었냐와는 관계없이 처리 요청 가능- 도메인 오브젝트가 기존 데이터 액세스 계층이나 기반 계층의 기능을 직접 활용
- AspectJ AOP를 이용해 스프링 빈이 아니여도 DI 적용이 가능하도록 만듦
도메인 계층을 만듦으로서, 서비스 계층의 역할이 완전히 사라지는 것은 아니다.
- 도메인 오브젝트의 기능을 조합해 복잡한 작업을 진행하는 경우, 도메인 계층과 협력
- 도메인 계층을 거치지 않고 바로 데이터 액세스 계층으로부터 정보를 가져오는 경우 인터페이스 역할을 담당.
- 트랜잭션 경계 설정 및 애플리케이션에서 필요한 기반 서비스를 이용해야하는 작업
▪ 고려해야할 사항
도메인 오브젝트가 도메인 계층을 벗어나서도 사용되게 할지 말지 결정해야 한다.
- 모든 계층에서 도메인 오브젝트를 사용한다.
- 도메인 계층 뿐만이 아닌 서비스,프레젠테이션,뷰 계층에서도 사용가능하게
- 막강한 기능을 가진 도메인 오브젝트이므로 함부로 사용하면 위험- 도메인 계층을 벗어나지 못하도록 하기
- 도메인 계층을 벗어날 때는 별도로 주비된 정보 전달용 오브젝트에 도메인 오브젝트의 내용을 복사하여 넘겨줌 - DTO(Data Transfer Object)
▪ 단점
- 도메인 오브젝트는 매우 짧은시간 존재하다가 사라짐을 반복함
- 상태정보를 지니고 있어 싱글톤이 될수 없음.
- DAO, 컨트롤러, 스프링 외의 라이브러리를 이용해 오브젝트가 만들어지는 경우가 많기 때문에 싱글톤 빈으로 등록할 수가 없음
❗ 이럼에도 도메인 계층을 택하는 이유?
매우 복잡하고 변경이 잦은 도메인이 존재할 때 최대한 오브젝트에 반영하여 빠르게 대응하여 변경해주기 위해서
◼ DTO와 리포트 쿼리
오브젝트 중심 아키텍처이더라도 항상 도메인 오브젝트에 모든 정보를 담지 않음
- 도메인 계층 방식의 경우 DTO 사용
- DTO : 특정 계층에 종속되지 않는 정보 전달의 목적을 가진 단순 오브젝트
- 리포트 쿼리(DB의 실행결과)를 담는 경우에도 DTO 사용
📝 스프링 애플리케이션을 위한 아키텍처 설계
◼ 계층형 아키텍처
3계층 구조는 스프링을 사용하는 엔터프라이즈 애플리케이션의 대표적인 구조
- 3계층은 논리적,개념적인 구분이지 오브젝트 단위로 딱 끊어져서 만들어진게 아님
- 서비스 계층을 굳이 도입할 필요가 없을 정도로 비즈니스 로직이 단순하다면 서비스 계층과 데이터 액세스 계층을 통합할 수도 있는 것
프레젠테이션 계층은 보통 MVC라는 이름으로 잘 알려진 패턴 또는 아키텍처를 주로 사용
프레젠테이션 계층은 특히 그 경계를 애플리케이션이 배치된 서버를 떠나서 클라이언트까지 확장하기도 함. - SOFEA(Service Front End Architecture)
⁕ 스프링을 처음 학습하고 도입하는 입장이라면 가장 전통적인 3계층에 먼저 익숙해지자.
- 프레젠테이션 - SpringMVC
- 서비스계층 - POJO로 구현하며 트랜잭션 AOP적용
- 데이터 액세스 계층 - JDBC를 비롯해서 JPA,하이버네이트,JDO 등을 활용
◼ 정보 전송 아키텍처
스프링의 기본 기술에 가장 잘 들어맞고 쉽게 적용 가능한 것은 도메인 오브젝트 방식이며, 그중 빈약한 오브젝트 방식으로 시작하는게 가장 쉽다.
- 도메인 오브젝트를 활용해 애플리케이션의 정보를 일관된 형태로 유지하는 것이 스프링에 가장 잘 들어맞는 방식
◼ 상태 관리와 빈 스코프
아키텍처 설계에서 한 가지 더 신경써야 할 사항은 상태 관리다.
- 엔터프라이즈 애플리케이션은 특정 사용자가 독점하여 사용하는 것이 아닌 수많은 사용자들이 사용
- 많은 요청을 제한된 리소스로 처리하기위해 간단한 형태로 저장 후 폐기함.
- 따라서 서버 기반의 애플리케이션은 지속적으로 유지되는 상태를 가지지 않음
- 하지만, 장시간 진행되는 작업 정보와 애플리케이션 상태는 유지되어야 한다.
- 스프링은 기본적으로 상태가 유지되지 않는 빈과 오브젝트 사용을 권장
-- 개발이 쉽고, 웹의 생리에 잘 들어맞으며 서버를 확장하기도 쉬움
◼ 서드 파티 프레임워크, 라이브러리 적용
스프링은 거의 대부분의 자바 표준 기술과 함께 사용될 수 있다.
표준 기술외에도 오픈소스 프레임워크, 라이브러리나 상용제품도 사용가능
- 이때, 스프링이 지원하는 기술인지 확인해보아야한다.
=> 스프링이 지원하는 기술이란 무슨 의미일까?
▪ 해당 기술을 스프링의 DI 패턴을 따라 사용 가능
프레임워크나 라이브러리의 핵심 클래스를 빈으로 등록가능하도록 지원해주는 것
- 코드를 초기화해야만 사용할 수 있던 기능을 빈을 등록하는 것 만으로 사용 가능
- 빈으로 바로 등록 불가능하다면 앞서 배웠던 팩토리 빈을 도입하여 생성해야 함.
▪ 스프링의 서비스 추상화가 적용됨
비슷한 기능을 제공하는 기술에 대한 일관된 접근 방법을 정의해줌
- 엄밀하게 적용된 표준은 아니지만 표준 기술을 사용하듯이 코드 작성이 가능해짐
- 서드파티 프레임워크 적용가능
- 호환 가능한 기술로 쉽게 교체해 사용가능
▪ 스프링이 지지하는 프로그래밍 모델 적용
대표적인 예 : 데이터 액세스 기술에 대한 일관된 예외 적용
- 데이터 액세스 기술의 종류에 상관없이 일관된 예외 계층구조를 따라 예외가 던져짐.
- 서비스 계층의 비즈니스로직을 담은 코드가 데이터 액세스 계층의 기술에 종속되지 않도록 만들어줌
▪ 템플릿/콜백이 지원됨
스프링은 JDBC,JMS,JCA를 비롯한 20여 가지 기술을 지원하는 템플릿/콜백을 제공
