토비의 스프링 3.1 Vol.1 750p ~ 850p 정리 (완료)

8.5 정리

- 스프링은 그 개발철학과 목표를 분명히 이해하고 사용해야 한다.

- 스프링은 오픈소스 소프트웨어이며, 애플리케이션 개발의 모든 기술과 영역을 종합적으로 다루는 애플리케이션 프레임워크다.

- 엔터프라이즈 애플리케이션 개발의 복잡함은 비즈니스 로직과 엔터프라이즈 시스템의 기술적인 요구에 의해 발생한다. 기존의 접근 방법은 이 복잡도를 낮추지 못하며 자바의 객체지향적인 장점을 포기해야 한다는 문제점이 있다.

- 자바의 근본인 객체지향적인 원리에 충실하게 개발할 수 있으며, 환경과 규약에 의존적이지않은 POJO를 이용한 애플리케이션 개발은 시스템 개발의 복잡함이 주는 많은 문제를 해결할 수 있다.

- 스프링의 목적은 이런 POJO를 이용해 엔터프라이즈 애플리케이션을 쉽고 효과적으로 개발할 수 있도록 지원해주는 데 있다.

- POJO 방식의 개발을 돕기 위해 스프링은 IoC/DI, AOP, PSA와 같은 가능기술을 프레임워크와 컨테이너라는 방식을 통해 제공한다.

9장. 스프링 프로젝트 시작하기

9.1 자바 엔터프라이즈 플랫폼과 스프링 애플리케이션

스프링은 주로 자바 엔터프라이즈 환경에서 동작하는 애플리케이션을 개발하는 목적으로 사용된다.

9.1.1 클라이언트와 백엔드 시스템

가장 많이 사용되는 구조는 클라이언트가 웹 브라우저이고 백엔드 시스템이 DB인 구성이다.

간단히 'DB를 사용하는 웹 애플리케이션'이라고 한다.

9.1.2 애플리케이션 서버

- 경량급 WAS/서블릿 컨테이너

- WAS

 

- 스프링소스 tcServer

톰캣을 기반으로 엔터프라이즈 스프링 애플리케이션에 최적화된 경량급 애플리케이션 서버

오픈소스 제품인 톰캣을 그대로 사용하기 불안하다면 tcServer가 좋은 대안이다.

 

9.1.3 스프링 애플리케이션 배포 단위

- 독립 웹 모듈

- 엔터프라이즈 애플리케이션

- 백그라운드 서비스 모듈

9.2 개발도구와 환경

9.2.1 JavaSE와 JavaEE

 

- JavaSE/JDK

- JavaEE/J2EE

 

9.2.2 IDE

이클립스, 넷빈즈, IntelliJ IDEA 등등

9.2.3 SpringSource Tool Suite

- SpringIDE 플러그인

1. 빈 클래스 이름 자동완성

2. 빈 설정 오류 검증 기능

3. 프로젝트 생성, 설정파일 생성, 빈 등록 위저드

4. 빈 의존관계 그래프

5. AOP 적용 대상 표시

 

- STS 플러그인 / 서버 배치, tcServer, etc..

- 기타 플러그인

1. M2Eclipse

2. AJDT

3. VMCI

4. 이클립스 표준 플러그인

9.2.4 라이브러리 관리와 빌드 툴

- 라이브러리 관리의 어려움

- 라이브러리 선정

1. 스프링 모듈

2. 라이브러리

 

- 빌드 툴과 라이브러리 관리

Maven이나 ANT는 자바의 대표적인 빌드 툴이다.

 

- 스프링 모듈의 두 가지 이름과 리포지토리

9.3 애플리케이션 아키텍처

9.3.1 계층형 아키텍처

 

- 아키텍처와 SoC

책임과 성격이 다른 것을 크게 그룹으로 만들어 분리해두는 것을 아키텍처 차원에서는 계층형 아키텍처라고 부른다.

또는 계층이라는 의미를 가진 영어 단어인 티어를 써서 멀티 티어 아키텍처라고도 한다. 보통 웹 기반의 엔터프라이즈 애플리케이션은 일반적으로 세 개의 계층을 갖는다고 해서 3계층 애플리케이션이라고도 한다.

 

- 3계층 아키텍처와 수직 계층

데이터 액세스 계층 - 백엔드의 DB나 레거시 시스템과 연동하는 인터페이스 역할

서비스 계층 - 비즈니스 로직

프레젠테이션 계층 - 흐름 관리

 

1. 데이터 액세스 계층

DAO 계층이라고도 불린다.

2. 서비스 계층

잘 만들어진 스프링 애플리케이션의 서비스 계층 클래스는 이상적인 POJO로 작성된다.

 

- 계층형 아키텍처 설계의 원칙

자신의 역할과 기술에만 충실한 계층을 만들면 각 계층 사이의 결합도는 자연스럽게 낮아진다.

어떤 경우에라도 계층 사이의 낮은 결합도를 깨뜨리지 않도록 설계해야 한다.

9.3.2 애플리케이션 정보 아키텍처

엔터프라이즈 시스템은 본질적으로 동시에 많은 작업이 빠르게 수행돼야 하는 시스템이다.

 

- DB/SQL 중심의 로직 구현 방식

데이터 중심 구조의 특징은 하나의 업무 트랜잭션에 모든 계층의 코드가 종속되는 경향이 있다는 점이다.

스프링 애플리케이션 개발에도 DB 중심의 아키텍처를 선택한다면 스프링의 장점을 제대로 누릴 수 있는 기회를 얻지 못할 것이 분명하다.

 

- 거대한 서비스 계층 방식

데이터 중심 아키텍처의 특징은 계층 사이의 결합도가 높은 편이고 응집도는 떨어진다.

 

9.3.3 오브젝트 중심 아키텍처

오브젝트 중심 아키텍처는 객체지향 분석과 모델링의 결과로 나오는 도메인 모델을 오브젝트 모델로 활용한다.

 

- 데이터와 오브젝트

public class Category {
	int categoryid;
    String description;
    Set<Product> products;
}

public class Product{
	int productid;
    String name;
    int price;
    Category category;
}

 

- 도메인 오브젝트를 사용하는 코드

- 도메인 오브젝트 사용의 문제점

사용하지 않는 정보를 매번 가져와야 하는 낭비가 생긴다.

그러나 다양한 기법을 활용하면 SQL을 직접 만들어 쓰는 경우 못지않게 성능을 향상 시킬 수 있다.

 

- 빈약한 도메인 오브젝트 방식

도메인 오브젝트에 정보만 담겨 있고, 정보를 활용하는 아무런 기능도 갖고 있지 않다면 이는 온전한 오브젝트라고 보기 힘들다.

이런 오브젝트를 빈약한 오브젝트라고 부른다. 그렇더라도 도메인 모델을 반영한 오브젝트에 정보를 담아 활용하는 편이 도메인 오브젝트를 전혀 사용하지 않는 것보다는 훨씬 낫다. 이런 빈약한 오브젝트 방식도 많이 사용된다.

이 방식은 거대 서비스 계층 방식의 한계와 유사하다. 로직의 재사용성이 떨어지고 중복의 문제가 발생하기 쉽다. 그러나 비즈니스 로직이 복잡하지 않다면 가장 만들기 쉽고 3계층 구조의 특징을 잘 살려서 개발할 수 있는 유용한 아키텍처이다.

 

- 풍성한 도메인 오브젝트 방식

도메인 오브젝트 방식의 단점을 극복하고 도메인 오브젝트의 객체지향적인 특징을 잘 사용할 수 있도록 개선한 것이다.

public class InventoryService {
	public void complexInventoryAnalysis() {
    	...
        int total = category.calcTotalOfProductPrice();
        ...
	}
}

 

- 도메인 계층 방식

- DTO와 리포트 쿼리

9.3.4 스프링 애플리케이션을 위한 아키텍처 설계

- 계층형 아키텍처

굳이 서비스 계층을 도입하지 않아도 될 만큼 비즈니스 로직이 단순한 애플리케이션이라면 서비스 계층과 데이터 액세스 계층을 통합할 수 있다. 반대로 프레젠테이션 계층에 서비스 계층을 통합하는 방법도 가능하다.

 

- 정보 전송 아키텍처

객체지향적인 도메인 분석과 모델링에 자신이 있고 도메인 오브젝트 설계와 구현, 독립적인 테스트를 자유롭게 적용할 수 있다면 과감하게 도메인 계층 방식을 도입할 수도 있다. 다만 도메인 계층에 DI를 적용하기 위해 스프링의 고급 기술을 활용해야 하고 여러 가지 고려할 점이 많으므로 충분한 사전 학습과 검증이 먼저 진행돼야 한다.

 

- 상태관리와 빈 스코프

- 서드파티 프레임워크, 라이브러리 적용

스프링이 지원하는 기술이란 무슨 의미일까?

1. 해당 기술을 스프링의 DI 패턴을 따라 사용할 수 있다.

2. 스프링의 서비스 추상화가 적용됐다.

3. 스프링이 지지하는 프로그래밍 모델을 적용했다.

4. 템플릿/콜백이 지원된다.