[SPRING] SPRING MVC 웹 프로그래밍 3장

2014년 4월 13일 선릉 토즈 오전 10시 

3장 웹 어플리케이션 아키텍쳐

1. MVC 패턴

기존에 비쥬얼 베이직이나 SWING 프로그래밍에서 적용하던 모델 방식으로 

MVC로 나뉘며 

VIEW는 모델을 사용해서 렌더링 하는 역할 이것은 사용자의 액션을 보고 컨트롤러에게 알린다.

CONTROLLER는 모델을 업데이트하고

MODEL은 뷰에게 렌더링을 요청한다.

MVC는 관심사의 분리를 충실히 이행한다. 관심사의 분리를 통해서 다른 관심사에게 영향을 주지 않고 오로지 본연의 할 역할만 충실히한다. VIEW는 비지니스 모델과 데이터에 대한 부담을 덜게 된다. 

이 얘기인 즉슨 관심사와 역할을 분리해서 전문성있게 임무를 전담시킴으로서 테스트와 유지보수에 유리하다.

2. MVC2

기본에 MVC는 스윙 기반의 테스트톱 에플리케이션에서 사용하던 방식이었지만 웹 에서는 구현 방식 자체가 달라 이것그대로 적용하긴 어렵다. 웹 환경에 특화된 나름대로의 패턴 구현방식으로는 아래와 같다.

웹 특성상 HTTP 설계상태 '무' 상태 이기 때문에 요청 작업을 처리하는 동안 모델을 유지해야만한다. 

무(stateless) : 빈이 상태를 계속 유지하지 않는 상태

       

그래서 MVC2로 구현이 가능하다. 기반은 MVC에 있으면서 HTTP 특성상 프론트 컨트롤러를 둠으로써 이 같은 환경에서 구현이 가능하게 만들었다. 우리가 흔히 보는 Spring에서 사용하는 패턴이 바로 이 패턴이라 보면 되겠다.

여기서 프론트 컨트롤러는 Dispatcher-servlet이 라고 할 수 있겠다.

v사용자에게서 들어오는 요층을 프론트 컨트롤러를 통해서 서비스 컨트롤러에게 요청을 처리하게 위임하거나 모델 객체에 대한 렌더링을 뷰 템플릿에 요청하는 방식이 되겠다. 작동 방식에 있어서 거의 중심적인 역할을 한다.

4. 어플리케이션 레이어

어플리케이션 레이어는 개념적인 레이어이며 설계에서의 프로그램의 관심사의 분리 정도로 이해한다. 같은 관심사 같은 횡단 공통된 관심사들에 대해서 레이어를 추출하고 그 레이어에 대해서 AOP를 적용하여 관심사를 관리한다.

일반적인 레이어의 모습을 이렇다

Presentation

Service

Data Access

여기서 프레젠테이션 레이어는 화면에 표출되는 부분인 VIEW 정도로 이해하가ㅗ 

Service는 비지니서 로직이 포함되어 데이터를 핸들링하는 부분

Data Access는 실질적으로 데이터베이스에서 데이터를 물고 가지고 오는 부분이라고 이해하자.

프레젠테이션, 서비스, 데이터 엑세스 레이어를 전부를 걸쳐있는 Domain Layer도 있다.

예를 들어 우리가 DAO에서 들고 Domain 객체를 화면까지 들고가서 출력하니까 라고 쉽게 이ㅐ하자.

하지만 확실히 해야 할 것은 여기서 얘기하는 

doamin, vo,dto는 다 다르다. 비슷하면서도 다르니 사용하는데 의미를 알아야 한다.

domain은 DDD에서의 domain이고 하나의 업무 관점이 이르러 비지니스 로직을 포함하고 있는 객체를 얘기한다. 즉, 이 domain하나로 분리된 하나의 업무를 처리하는 객체라고 이해하면 된다. 

예를 들어 사용자 조회라고 할 경우 사용자를 조회하기 위해서 수행 해야할 비지니스 로직과 조회로 인한 데이터까지 domain객체가 가지고 있게 된다. 이 domain 레이어ㅣ는 프레젠테이션, 서비스, 데이터 엑세스 레이어에 걸쳐서 존재한다.

VO객체와 DTO는 흔히 DAO에서 데이터베이스를 조회하고 조회된 데이터를 담고 있는 객체로 단순히 데이터를 전달하는 객체라고 이해하면 된다. 

5. 관심사의 분리

관심사를 철저히 분리하는 것이 좋으며 그 관심사의 철저한 분리를 통해서 추출 되는 것들이 레이어다.  관심사를 각기 다른 레이어로 분리하면 설계가 깔끔해지고 애플리케이션이 유연해지며 테스트가 용이해진다.

커플링된 레이어는 정리하면 깔끔해진다.

여기서 커플링이란 단어가 나오는데 난 쉽게 이렇게 이해했다. 이 장의 관점으로 보자면 하나의 레이어에 여러개의 관심사가 얽혀있는 것이거나 복잡한 어떤 것,

을 디커플링하여 레이어로 정리하게 되면 깔끔해진단 얘기다.

인터페이스를 정의하고 인터페이스에 프로그래밍하면 실제 구현체에 대한 커플링이 줄어든다. 

6. 스프링 MVC 애플리케이션 레이어

위와 같이 일반적으로 프레젠테이션, 데이터엑세스, 서비스 레이어에 도메인 레이어가 세개의 레이어에 전반적으로 걸쳐있는 형태의 구성이 나온다. 

가장 일반적인 레이어 형태이며 스프링 MVC 애플리케이션에서의 레이어는 다음과 같다.

도메인 레이어는 비지니스 문제를 코드로 나타내며 도메인의 비지니스 규칙도 포함한다. 

유저 인터페이스 레이어는 사용자에게 애플리케이션을 보여주는 역할을 한다. 다양한 뷰 기술이 있다면 재활용을 위해 프레젠테이션 레이어를 유저 인터페이스 레이어와 웹 레이어로 나눈다. 

웹 레이어는 사용자를 웹 어플리케이션으로 연결하는 역할이고 서비스 레이어와 HTTP를 연결해주는 통합 레이어 역할이다.

스프링에서의 웹 레이어는 @Controller로 구현되어 있는 클래스로 표현된다.

서비스 레이어는  사용자에게 시스템의 기능을 노출하기 때문에 애플리케이션의 핵심이라고 할 수 있다.

여기서 서비스 레이어는 AOP를 통해서 서비스 전반에 이를 적용할 수 있다며, 사용자가 동시에 서비스를 요청하는 경우가 있다. 이때 서비스는 싱글톤으로 만들져야 하며 도메인과는 분리되어 서비스는 상태를 갖지 않아야 된다. 그래야만이 Thread safe하게 된다는 점이다. 서비스가 상태를 갖게 되면 여러 사용자의 요청에 대해서 대응하지 못할 뿐더러 사용자 입장에서는 원치 않은 데이터를 보게 될 것이다. 

서비스 레이어에서는 한가지 이상의 도메인 객체가 조합되어 사용된다는 것을 알 수 있다. 

데이터 엑세스 레이어는 시스템의 퍼시스턴스와 데이터를 주고 받는 역할을 한다. repository정도로 이해하면 된다. 즉, 데이터 엑세스 하는 관심사를 분리하여 레이어로 구성하게 되면 해당 서비스 레이어에서는 어떤 데이터베이스를 사용하는지 신경쓰지 않아도 된다. 즉 JDBC에서 하이버네이트로 전환한다거나 하는 것들이 가능하다.

이외

POJO는 그냥 개념이다. 자바 오브젝트 즉, 멤버변수와 setter와 getter로 이루어진 자바 value object를 얘기하며 java beans랑 ejb bean이랑 구분하기 위해 지어졌다.

로마로 통하는 길은 다양하다. 관심사를 분리하는 관점에 따라서 여러개의 레이어가 다르게 구성될수도 있고 시스템에 더 적합한 레이어를 구성할 수도 있다. 관심사를 레이어로 잘 분리하면 공통적인 관심사에 대해서 AOP를 적용하여 관리할 수도 있다며 유지보수의 편의성과 테스트의 편의성까지 득템하게 되니 실로 관심사의 분리는 중요하다고 할 수 있다. 

JPA도 그냥 단순히 스펙일 뿐이다.

그것을 구현할 수 있게 만들어 놓은것이 hibernate이다. 

mybatis ibatis는 ORM이 아니고 sql Mapper일 뿐이다. 

orm을 적용하기 위해서는 섣불리 접근해서는 안되며 충분한 고려없이 시스템에 반영해서는 안된다. 팀이 이것을 적극적으로 이끌어갈 자세나 의지가 되어 있는지 그리고 시스템 특성을 잘 고려하여 orm을 사용할 것을 권장한다 하였다. 기본적으로 hibernate는 sql 표준을 사용하여 데이터를 핸들링하며 설계된 객체를 통해서 테이블을 생성하고 작동시킨다. 통계쿼리가 아니면 거의 CRUD는 쿼리문 없이 사용가능하며 sql에 대한 튜닝이 불가능하여 여러곳에서 의문의 목소리가 나올 수도 있다. 

하지만 꼭 써보야 한다. 이게 대세이기 때문에!! 

근데 책이 없어!!

아 어렵다..