스프링 프로젝트 시작하기

애플리케이션 프로젝트 처음 구성할때 기본적인것 알아보기

스프링 개발에 도움되는 개발 툴 및 빌드방법도 살펴보자
애플리케이션에 적용 할 수 있는 아키텍처의 종류와 특징에 대해서도 알아보자

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

스프링이 만들수 있는 애플리케이션 종류에는 제한이 없음

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

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

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

간단히 DB를 사용하는 웹 애플리케이션

스프링의 주요 기능은 웹브라우저를 클라이언트로 하고 DB 저장 조회 하는데 집중

애플리케이션 서버

스프링으로 만든 애플리케이션을 자바 서버 환경에 배포하려면 JavaEE 서버가 필요

JavaEEd의 대부분 표준 기술을 지원함.
다양한 형태의 모듈로 배포가능한 완전한 웹 애플리케이션 서버 WAS , 다른 하나는 웹 모듈의 배포만 가능한
경량금 WAS 또는 서블릿/JSP 컨테이너다

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

스프링은 기본적으로 톰캣이나 제티 같은 가벼운 서블릿 컨테이너만 있어도 충분함

WAS

WAS는 상대적으로 관리 기능이나 모니터링 기능이 뛰어남
여러 대의 서버를 동시에 운영할 때 유리한 점이 많다.

자바 엔터프라이즈 버전표준을 최대한 활용 가능함

스프링 개발은 비용이 좀 들더라도 적합한 WAS 사용 권장

스프링소스 tcServer

개발 환경과 운영환경에서 가장 많이 사용되는 자바 서버는 웹 모듈만 지원하는 아파치 톰캣임

tcServer를 이용하면 기존 톰캣에서는 아쉬웠던 고급 서버 관리 기능 , 배포 기능 진단 기능을 포함해서
톰캣전문가에게 받는 기술지원도 함께 제공받을 수 있다.

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

1. 독립 웹 모듈

스프링은 보통 war로 패키징된 독립 웹 모듈로 배포됨

독립 웹 모듈이 가장 단순하고 편리한 배포 단위.

WAS로 배포 할때 사용하는 경우가 대부분

2. 엔터프라이즈 애플리케이션

경우에 따라 Ear인 엔터프라이즈 애플리케이션으로 패키징해서 배포 함

별도로 분리된 공유 가능한 스프링 컨텍스트를 엔터프라이즈 애플리케이션으로 묶어주는 방법

3. 백그라운드 서비스 모듈

J2EE 1.4에 등장한 rar패키징 방법도 있음

리소르 커넥터를 만들어 배포할 때 사용하는 방식

백그라운드 서비스처럼 동작할 때 사용

개발 도구와 환경

JavaSE와 JavaEE

JavaSE/JDE

스프링은 기본적으로 JDK 5.0 그 이상이 필요

JavaEE/J2EE

스프링이 사용될 자바 엔터프라이즈 플랫폼으론J2EE 1.4 버전이나 JavaEE 5.0 이 필요함

IDE

스프링 애플리케이션은 자바 5 또는 그 이상의 언어를 지원하는 자바 개발도구와 스키마를 지원하는 XML 편집기 정도만

있다면 어떤 개발환경에서는 불편 없이 개발 가능.

또 Maven /ANT 빌드 툴 지원 톰캣이나 자바서버로 배포해서 실행해볼 수 있는 환경이면 더 좋다.

SpringSoruce Tool Suite

스프링 개발업체인 스프링소스가 직접 만들어 제공하는 이클립스의 확장 판인 STS 사용 고려.

SpringIDE 플러그인

플러그인 사용하면 XML 등 좀더 편리하게 사용가능

전이적 의존 라이브러리 추적기능.

한 라이브러리를 추가할때 그 라이브러리의 동작에 필요한 라이브러리도 다운로드

현재 회사에서 사용하고 있는 구조랑 비슷하다.

이런 DB 중심 종속적 아키텍처는 스프링의 장점을 누리기 힘들다.

거대한 서비스 계층 방식

DB에서 가져온 데이터가 애플리케이션에 흘러다니는 정보의 중심이 되는 아키텍처이긴 하지만
DB에 많은 로직을 두는 개발 방법의 단점을 피하면서

애플리케이션 코드의 비중을 높이는 방법이 있다.

주요 로직은 서비스 계층의 코드에서 처리하도록 만드는 것

이런 방식으로 개발하다 보면 서비스 계층에 코드가 방대해져서

거대한 서비스 계층 방식이 된다.

오브젝트 중심 아키텍처

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

오브젝트를 만들어두고 오브젝트 구조 안에 정보를 담아서 각 계층 사이에 전달하게 만드는 것이

오브젝트 중심 아키텍처다.

DAO는 데이터 구조를 알고 있어야 된다. 데이터 중심 아키텍처에서..

DAO가 만드는 SQL 결과에 모든 계층의 코드가 의존..

이 구조는 단순히 특정 SQL 에 대응되는 맵과 배열 매번 달라지는 SQL 담기위해 급조해서 만든 오브젝트와 달리

애플리케이션 어디서도 사용될 수있는 일관된 형식의 도메인 정보를 담고 있음

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

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

성능면에선 손해를 감수해야 됨.

필드 전체를 불러오기때문에 잘안쓰는 필드도 같이 옴..

지연된 로딩 기법을 사용해 최소한의 오브젝트 정보만 읽어두고 관계하고 있는
오브젝트가 필요한 경우에만 동적으로 DB에서 읽어올 수 있다.

이상적인 방법은 JPA / JDO 하이버네이트 TopLink 와 같은 오브젝트 RDB 매핑 기술 사용하는 것

지연된 로딩 기법을 이용함.

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

도메인 오브젝트에 정보만 담겨 있고 정보를 활용하는 아무런 기능을 갖고 있지 않으면

빈약한 오브젝트라 함.

특정 계층에 종속되지 않으면서 애플리케이션 전반에서 사용 될 수 있는 정보를 담은 오브젝트가
필요하기 마련이고 그래서 빈약한 도메인 오브젝트 방식도 실제로 많이 사용됨.

비즈니스 로직이 복잡하지 않는경우 이런식으로 만들면 좋다.

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

도메인 오브젝트의 객체지향적인 특징을 잘살려 개선함.

이런식으로 도메인안에 로직을넣어주면 코드가 간소화됨.

도메인 오브젝트는 DAO 오브젝트를 DI 받을 수 없을까?

도메인 오브젝트는 스프링 컨테이너가 관리한느 오브젝트 , 즉 빈이 아니기 때문

자기 자신과 관련된 로직은 오브젝트 내에 넣을수 있지만

디비에 저장하거나 메일 발송등 디비를 검색해서 원하는 정보를 가져와 활용하는 작업은 불가능

서비스 계층의 코드가 필요함

도메인 계층 방식

기존 3계층고 같은 레벨에서 하나의 계층으로 이루어지는 방식

1. 도메인에 종속적인 비즈니스 로직의 처리는 서비스 계층이 아니라 도메인 계층 오브젝트 안에서 진행됨

2. 도메인 오브젝트가 기존 데이터 액세스 계층이나 기반 계층의 기능을 직접 활용할 수 있다는 것.

   AOP 를 이용해 DI 해준다 . 부가기능을 추가할 수 있는 위치가 메소드 호출과정으로 한정되고.
   AOP의 적용 대상도 스프링의 빈 오브젝트 뿐이다.

   AspectJ AOP 를 사용하면 클래스의 생성자가 호출되면서 오브젝트가 만들어지는 시점을
   조인 포인트로 사용할 수 있고 스프링 빈이아닌 일반 오브젝트에도 AOP 부가기능 적용 가능함

   도메인 오브젝트를 독립적인 계층으로 만들려 할때 고려해야될 사항이 있음.
   도메인 계층을 벗어나서 사용되게 할지 말지.

3. 여전히 모든 계층에서 도메인 오브젝트를 사용한다.

   가장 손쉬운 방법 오브젝트 중심 아키텍처의 장점을 그대로 누림

   하지만 주의하지않으면 혼란 초래.

   철처히 개발 가이드라인을 만들어 강력하게 적용해서 문제 해결.

4. 도메인 오브젝트는 도메인 계층에서 벗어나지 못하게 한다.

   전달용 오브젝트를 통해 복사해서 넘겨주기로 한다

   이런 오브젝트를 DTO라 부른다 DTO는 상태변화 하지않고 읽기전용으로

   

   계층형 아키텍처

   프레젠테이션 계층은 보통 MVC라는 이름으로 잘 알려진 패턴 또는 아키텍처를 주로 사용