한빛미디어 스프링3 입문이란 책을보며 공부한 내용을 블로그에 포스팅하려고 합니다.>>
스프링의 등장은
J2EE가 점점 무거워지며 웹 어플리케이션 개발에 좀 더 가벼운 컨테이너를 이용하기 위해 경량급으로 고안된 프레임워크.
하지만 요즘엔 기능과 제품이 더해져서 더이상 경량이라고 안부른다고 함.
|
경량컨테이너 POJO(plain old java Object) 컨테이너나 프레임워크 등에 의존하지 않는 일반 오브젝트의 생애주기 관리나 오브젝트간에 의존관계를 해결해주는 아키텍처를 구현하는 컨테이너를 말함.
애플리케이션 아키텍처 애플리케이션 전체의 구조, 매커니즘으로 정의됨. 시스템의 어플리케이션이 공통으로 이요할 수 있는 사용자 인터페이스 구조나 DB접근방식등 시스템의 기반이 되는 부분을 말함. 웹 애플리케이션의 생애주기는 (요건의변화 > 변경&기능추가 >릴리즈 >요건의변화) 의 순환이며 기능추가, 변경에 대한 용이성이 아키텍처의 목표이다. |
티어와 레어
: 웹 어플리케이션의 아키텍처는 티어(물리층)과 레이어(논리층)으로 구분한다.
티어는 클라이언트층(PC, 스마트폰 등..) + 중간층(애플리케이션 서버) + ELS층(DB..)으로 구분한다.
레이어는 단방향 엑세스라는 특징을 가지고 있으며 프레젠테이션층, 비즈니스로직층, 데이터액세스층으로 나뉜다.
프레젠테이션 층 : UI와 컨트롤러를 제공한다. 클래스이름으로 Controller나 Action이 붙음.
컨트롤러 : 화면 전환이나 화면에서 버튼이 눌렸을 때 동작 제어나 세션 관리등을 한다.
비즈니스로직 층 : 비즈니스로직을 제공한다. service가 붙은 유스케이스를 제어하는 클래스나 회사나 종업원, 주문 등 업무대상의 이름을 붙힌 클래스가 온다.
서비스 : 유스케이스로 표현되는 특정업무나 특정부서 처리의 통합.
(?)도메인 : 서비스로부터 비즈니스를 실행함에 있어 당연히 인식되는 고객이나 주문같은 클래스의 집합이다. 자신이 무엇인지 나타내는 값과 그 값을 이용한 처리를 실현한다.
데이터 엑세스층 : DB엑세스를 추상화한다. 클래스 이름 끝에 DAO가 온다.
좋은설계?
브라우저에 표시하거나 RDB에 저장하는 기술 등에 비즈니스 로직이 영향을 받지 않는것이 좋은 설계라고 한다.
비즈니스 로직층이 시스템의 핵심이기 때문에 매커니즘이 변해도 영향을 받지 않게 만드는것.
안전의존성원칙과 의존관계 역전원칙등에 뒷받침된 꽤 건실한 구조라는 오목형레이어↓
결국 비즈니스 로직 층을 다른 층의 변경으로부터 분리하려면 시스템을 형식으로만 레이어어로 분류할 게 아니라 레이어의 결합 부분에 인터페이스를 도입한 약한 결합 설계나 구현을 고려할 필요가 있다.
프레젠테이션층의 역할
UI와 컨트롤러 제공이 주된 역할임.
컨트롤러는 MVC2라 불리는 JSP 모델로 잘 알려져있고 그 역할은
(1) 사용자로부터 입력을 받아 적절한 비즈니스 로직을 호출하고 그 결과를 화면으로 반환하는 작업을 한다.
(2) 웹 어플리케이션의 상태(세션)로 저장해 이용하는 데이터를 관리하는것이다.(?)
MVC2
Model 부분에 Java Beans, View 부분에 Jsp, Controller 부분에 Servlet을 사용함. MVC 패턴과 유사해함.
비즈니스 로직 층의 역할
서비스나 도메인 같은 비즈니스 로직을 구현하는 웹 어플리케이션의 중심이 된다. 기능의 추가나 변경은 주로 이 층에서 이뤄진다.
트랜잭션 : 처리단위를 말한다.
|
트랜잭션에서 지켜야 할 특징 : ACID (자세한 내용은 5장 언급이라네요) | |
|
Atomicity(트랜잭션의 원자성) |
트랜잭션 내의 모든 처리는 전부 실행했거나 혹은 아무것도 실행 안했거나이다. |
|
Consistency(데이터의 일관성) |
데이터에 일관성이 있어야 한다. |
|
Isolation(트랜잭션의 독립성) |
병행해서 달리는 트랜잭션이 서로 독립된 것 |
|
Durability(데이터의 영속성) |
데이터가 영속화 된 것 |
시스템을 구축 할 때 원자성의 범위를 정해 줄 필요가 있다. 보통 메소드가 시작할 때 트랜잭션이 시작되고 메소드를 빠져나오면 트랜잭션 커밋 혹은 롤백을 한다
( 트랜잭션시작 ) -> method{....return;} -> (트랜잭션 커밋 혹은 롤백)
트랜잭션 대상인 메소드가 모든 층에 흩어져 있으면 관리가 어렵기 때문에 트랜잭션의 시작과 종료가 되는 메소드를 정해둘 필요가 있다. 그 규칙이 트랜잭션의 경계션인데, 트랜잭션의 경계선은 프레젠테이션층과 비즈니스로직층 사이이다.
컨트롤러(프레젠테이션층) | [트랜잭션처리] | 서비스(비즈니스로직층)
명시적 트랜젝션과 선언적 트랜젝션
명시적 트랜젝션 : 트랜잭션의 시작, 커밋과 같은 RDB에 대한 트랜젝션 관리를 소스코드로 명시하는 것
선언적 트랜젝션 : 정의파일등을 선언해 프레임워크 등에서 트랜젝션 처리를 관리시키는것. 스프링이 여기에 속하고, 스프링을 이용하면 트랜젝션 관리에 신경을 덜 수 있기 때문에 다른곳에 더 신경쓸 수 있어 개발 효율이 증가하는 이유이기도 하다.
데이터 액세스층의 역할
데이터 액세스층은 비즈니스로직층으로부터 RDB액세스를 숨기고 비즈니스로직에 필요한 데이터를 RDB에서 가져와 오브젝트에 맵핑한다.
오브젝트와 RDB를 맵핑하는 것을 O/R매핑이라고 하는데 (O : obejct , R:relational) 이 층은 오픈소스의 DB액세스프레임워크(JDBC, MyBatis등..)를 이용하는게 일반적이다. 그 이유에 대해서 알아보자.
DB엑세스층의 설계 지침
1) 커넥션 풀링을 이용한다.
커넥션을 이용할 때 마다 생성하고 해제하는 것은 효율적이지 않기때문
2) RDB제품을 바꿔도 구현에 영향을 주지 않게 한다.
대부분의 데이터 엑세스 프레임워크에서 이용할 DB를 설정파일을 통해 지정하므로 영향을 주지 않게 할 수 있다.
3) 한가지는 애매하기도하고 확실히 이해가 안되서 생략.......
위의 설계지침들은 DB액세스 프레임워크에 모두 포함되므로 데이터 액세스층에서 따로 설계할 곳이 거의없다. 인터페이스만 설계하면 되는 것이다. 때문에 DB 액세스 프레임워크를 이용한다.
부품화
개발 효율성과 유연성을 향상시키기 위해 웹 애플리케이션을 부품화하고 부품끼리 인터페이스로 연결하자는 말이다.
(컴퓨터를 모니터, 마우스, 키보드 등으로 나누고 고장난 부품만 수리하는식이기 때문에 효율적이고 유연하다)
집고넘어갈점 ?
1) 두개의 부품이 있을 때 Interface의 정의가 어느 쪽에 있어야 하는가?
> 더 중요한쪽에 있어야 한다. 오목형 레이어의 사고방식에서는 비즈니스로직이 가장 중요하다.
2) 어느정도까지 부품화 해야 하는가?
> 부품화 할 필요가 있는 만큼만.......(?)
웹 애플리케이션이 안고있는 스프링에서는 해결해주는 문제점들
- 오브젝트의 생애주기 관리.
오브젝트가 너무 오래 살아남거나 그 반대의 경우 곤란해지며 또 사용자의 증가에 따라 가비지콜렉션의 성능 하락이나 메모리 압박이 올 수도 있다.
[부연설명] 컨트롤러를 구현하는 Servlet은 View에 액세스하는 사용자 수가 증가할 때 마다 성능하락을 막기 위해 멀티스레드로 동작시킨다. 컨트롤러에서 호출되는 서비스로직의 오브젝트를 매번 인스턴스화하게(?) 설계, 구현해버리면 view에 액세스하는 사용자수가 늘어났을 때 인스턴스가 증가해 성능하락의 우려가 있다.
- 부품화의 문제
(부품화) : 오브젝트 사이의 의존관계를 인터페이스를 매개로 해서 구현에 의존하지 않음으로써 오브젝트 사이의 약한 결합을 유지할 수 있고 개발효율 증가와 고품질화가 가능함
하지만 단순히 인터페이스를 이용하는 것만으로 인터페이스 의존 구현 비의존 등을 실현할 수 없다.
>> 스프링에서 해결 해줄 수 있다 : 부품화의 문제는 DI 컨테이너로, 오브젝트 생애주기 문제와 DI컨테이너 해결 , 기술은폐와 부적절한 기술 은폐 문제는 AOP로 해결
스프링 DIxAOP 컨테이너
스프링의 핵심이 되는 기능이며 프레젠테이션층, 비즈니스로직층, 데이터액세스층 모두 이용 가능함.
DI 컨테이너를 이용한 소프트웨어의 부품화로 요구사항 변경이 구현에 미치는 영향을 최소한에 그치게 할 수 있고, AOP를 이용해 선언적 트랜지션 관리를 할 수 있다.