스프링&웹 | 기초 지식 2 - 레이어별 책임

[ intro ]

 

지난 시간 : 웹 애플리케이션 아키텍처를 간단히 공부했다. 그 중 웹 애플리케이션을 논리적으로 분류하는 레이어 개념을 새로 알았다. 이번에는 레이어별로 어떤 책임을 가져야 하는지 공부한다.

 

레이어를 나누는 방법은 경우마다 다르지만 크게 이렇게 분류하기로 했다.

- 프레젠테이션 층

- 비즈니스로직 층

- 데이터액세스 층

 

대략적으로 각 레이어가 가져야 하는 역할, 책임, 설계지침을 알아보자.

(표/도표는 스프링4 입문 책에 있는 내용임)

 

---

1. 프레젠테이션 층

▶ 주 역할 : UI와 Contoller 제공

 

* UI

요즘에는 사용자의 요청이 많아지고 다양하게 발전하기 때문에 고정된 지침은 없다.

사용할 기술을 정했으면 그에 맞는 설계를 하면 된다.

참고) UI 구현 방법 예시 :  리액트, 앵귤러 이용

 

* Controller

화면에서 버튼을 눌렀을 때의 동작 제어 (사용자의 요청 처리) or 세션 관리 등을 한다.

: UI를 통해 사용자의 입력을 받아 적절한 비즈니스 로직을 호출하고, 그 결과를 UI로 반환하는 작업을 한다.

: 웹 애플리케이션의 상태(세션)를 저장해 데이터를 관리한다.

∨ 참고 : MVC 패턴은 크게 MVC1, MVC2 모델이 있고, 현재는 MVC2 모델이 표준이다. 

- MVC1은 V와 C가 분리되지 않아 Jsp가 뷰와 컨트롤러의 역할을모두 담당한다.

간단한 설계로 개발이 빠르지만, Jsp에 java코드, html, css가 섞여 있어 난잡하고 유지보수가 힘들다.

- MVC2는 V와 C의 역할을 분리한 것으로, Jsp는 뷰, Servlet이 컨트롤러 역할을 수행한다. 

앞으로 이야기할 컨트롤러는 MVC2의 컨트롤러다.

참고) MVC2의 컨트롤러는 JSP모델의 컨트롤러다.

* JSP 모델 : 프레젠테이션(표시부)과 비즈니스로직을 분리한 모델

 

∨ 프로젝트를 만들 때 처음부터 컨트롤러를 직접 만드는 것은 낭비이며 그렇게 하지도 않는다.

∨ 일반적으로 스프링 MVC나 오픈소스의 MVC 프레임워크에서 제공하는 컨트롤러를 이용한다.

 

 

---

2. 비즈니스 로직 층

▶ 서비스, 도메인 등 비즈니스 로직을 구현하는 웹애플리케이션의 중심, 핵심이다.

▶ 트랜잭션(=처리 단위) 관리하는 방법을 알자. 

 

* 도메인 : 고객, 주문처리 등을 구현한 클래스들의 집합

∨ 비즈니스 로직 층 구성 : 서비스 패키지 + 도메인 패키지

∨ 어느 클래스에 어떤 로직을 할당할지가 중요하며, 판단하기 어려운 문제며, 곧 설계 실력이다. 

∨ 웹애플리케이션의 기능 추가/변경 => 로직 변경

※ 프레젠테이션층, 데이터액세스 층에서는 괜찮은 프레임워크를 사용하면 리스크를 피할 수 있지만, 비즈니스로직에는 비교적 적절한 프레임워크가 적어서 매번 새로 만든다.

 

 

∨ 도메인 모델로 만드냐 vs 트랜잭션 스크립트로 만드냐

 

트랜잭션 스크립트	도메인 모델
로직 주도 설계	도메인 주도 설계 (Domain-Driven Design) : 도메인 모델을 생성하는 패턴/철학 (by 에릭 에반스)
도메인에 로직을 포함하지 X (객체지향 개념 적용 X) * 도메인은 단지 값을 저장하는 오브젝트!	객체지향의 이점
비즈니스 로직이 적은 단순 입출력(=>DB 내용을 표시/변경하기만 하는 처리)은 '서비스 클래스'에 로직을 포함하라는 일반적인 지침이 존재하는데, 이것이 바로 트랜잭션 스크립트의 경우이다.	복잡한 비즈니스 로직을 가질 경우 사용 * 이때 트랜잭션 쓰면 너무 장황, 복잡해진다.

다만 현실에서 도메인모델로 만들다가 막히면 그냥 트랜잭션 스크립트로 빨리 만들어버리는 것도 현명하다.

스프링은 도메인 모델에 대한 도움을 주진 않는다. 도메인 모델이랑 DIxAOP 컨테이너 기능이랑 상관 없다.

∵ 값을 가진 인스턴스(도메인)은 RDB와 통신하며 관리된다. 즉, 데이터 액세스 층의 구조에 의존한다. 

 

 

∨ 트랜잭션 관리하기

* 트랜잭션 : 처리 단위

* 트랜잭션 예시 : 웹사이트 검색 후 상품목록 보기까지 트랜잭션, 웹사이트에서 상품주문 후 집에 도착하기까지 트랜잭션, 주문을 받고 발주테이블을 관리하는 데이터베이스 트랜잭션 등 다양하고 유연하게 생각해볼 수 있다.

* 다만 이번 학습에서는 '데이터베이스 트랜잭션'을 이야기한다.

 

ㅇ 트랜잭션이 지키는 특성 : ACID

ACID	의미	설명
Atomicity	트랜잭션의 원자성	트랜잭션 내 모든 처리는 전부 실행됨 xor 아무것도 실행되지 않음
Consistency	데이터의 일관성	데이터에 일관성 있어야 함 (일관성 없는 예 : 상위table이 없는데 하위table이 있는 경우)
Isolation	트랜잭션의 독립성	병행해서 달리는 트랜잭션이 서로 독립임
Durability	데이터의 영속성	데이터가 영속화된 것 영속화된 데이터를 읽고 출력할 수 있는 것

* 영속성은 애플리케이션의 전제조건이다!

* 애플리케이션 아키텍처 : '원자성'과 '독립성'을 신경 써야 한다.

 

[ 원자성 ] : 트랜잭션 내 모든 처리는 전부실행 xor 아무것도실행안함

∨ 일단 트랜잭션(처리단위)를 정해야 한다 => 원자성의 범위 정하기 => 일반적으로 메서드에 들어가고 나오는 것임

∨ 원자적으로 처리되기 때문에, 트랜잭션이 시작되고 중단없이 모든 처리를 마치고 트랜잭션 커밋이 되어야 DB에 반영된다. 반면 시작 후 중간에 트랜잭션의 어떤 처리가 중단되면 트랜잭션 롤백이 되고, 이전 처리는 DB에 반영되지 않는다. 없었던 일로 한다. 

 

∨ 트랜잭션 대상인 메서드 내부에서 호출된 메서드 또한 모두 트랜잭션의 대상이다.

∨ 트랜잭션의 경계선 : 프레젠테이션 층과 비즈니스로직 층 사이다.

=> 프레젠테이션 층에 공개된 비즈니스 로직 층의 서비스 클래스 메서드가 트랜잭션의 시작/끝이다. 

- 프레젠테이션 층의 클래스에서 서비스 클래스의 메서드 호출 : 트랜잭션 시작

- 그 메서드 종료 : 프레젠테이션 클래스로 되돌아가고, 트랜잭션 종료

 

 

ㅇ 명시적 트랜잭션 vs 선언적 트랜잭션

* 지금은 간단히 넘어가자. 

명시적 트랜잭션	선언적 트랜잭션 (지향)
트랜잭션 시작, 커밋, 롤백과 같은 RDB에 대한 트랜잭션 관리를 소스코드로 명시	트랜잭션을 관리하기 위해 정의 파일로 선언하여 프레임워크의 트랜잭션 처리를 따름
신경쓸 것이 좀 있음	트랜잭션 의식 않고 개발에 전념 가능

 

 

---

3. 데이터 액세스 층

▶ 비즈니스 로직에 필요한 데이터를 RDB에서 얻어서 오브젝트에 매핑해준다. 

▶ 오브젝트와 RDB를 매핑하는 것 : O/R 매핑 (object, relational(table))

 

∨ O와 R

 

∨ O/R 매핑

O에서 R 매핑 (모델 퍼스트)	R에서 O 매핑 (데이터베이스 퍼스트)
객체지향 분석 - 엔티티를 추출하여 엔티티 바탕으로 테이블 작성 * 엔티티 : 도메인 클래스	- 시스템의 데이터 분석을 DOA등에서 처리해 테이블을 작성할 경우  - 시스템 개발 이전에 테이블이 이미 존재할 경우 사용
	단순 입출력 또는 참조용 웹 애플리케이션 : 표시할 데이터를 모아 한 오브젝트를 만드는 것이 효율적 => R/O 매핑 선택

 

 

∨ DB 액세스 프레임워크 - 일단 간단히 넘어가자

- 하이버네이트 (ORM, O/R 매핑 프레임워크)

잘 알려진 프레임워크다.

DB설계가 복잡한 경우 부적절하다고 함.

ㄴ우리나라에선 보통 Mybatis를 더 많이 사용한다고 함.

XML 등으로 기술된 매핑 파일이다.

단점 : 매핑 파일 작성이 귀찮다.

장점 : 개발자가 SQL문을 작성하지 않아도 된다.

- 스프링 JDBC, MyBatis

SQL 사용을 전제로 한 프레임워크

 

 

∨ 데이터 액세스 층의 설계지침 

: 사실 설계할 것이 거의 없다. DB 액세스 프레임워크가 설계지침을 지키기 때문이다. 

: 적절한 DB 액세스 프레임워크를 선택하면 된다.

O/R매핑, R/O매핑 따라 달라진다.

일단 이건 하지말고 넘어가자

 

 

---

∨ 부품화에 대한 간단한 이야기

어느 정도까지 부품화해야하는가 적절히 판단해야 한다.

불필요한 인터페이스를 추가하지 않도록 주의하고,

부품화할 필요가 있는 만큼 부품화하도록 고민하자. 

또 부품화에 따른 성능을 고민해보고,

잘 모르겠다면 기준을 3레이어로 시작하여 필요에 따라 늘리거나 줄이자. 

---

- 끝 -

 

∨ 올해는 자바 소프트웨어 구현 관련 도서를 참고해 프로젝트의 구조를 익히고 있다.

바로 그 책에서 "어느 클래스에 어떤 기능을 넣어야 ~~~가 좋은가" 이런 고민을 강조했고, 잘못된 방법에 대한 시행착오도 상세히 설명했고, 경험을 많이 해서 판단력을 길러야 한다고 했다. 

그 내용이 오늘 배운 '비즈니스로직 층에서 어느 클래스에 어떤 로직을 할당해야 하는가'에 대한 문제라는 것을 느꼈다. 바람직한 로직 구현에 대한 공부를 많이 해봐야겠다. 

 

아무튼.. 이렇게 각 레이어의 책임을 조금 더 자세히 공부해봤다.

 

 

 

∨ 다음 학습 :

웹 애플리케이션의 문제점과, 그것이 스프링으로 해결되는 이유에 대해 공부한다.