[Etc] Web Application Model

# Web Application

- 정적인 웹 애플리케이션의 기능을 그대로 사용하면서 동적인 (서블릿, Jsp, 자바) 서비스를 제공하는 프로그램

- 기존의 정적인 웹 애플리케이션 + 동적인 서비스

 

기본 구조

- 기본적으로는 웹 애플리케이션의 명칭인 상위 디렉토리(WEB-INF)와 애플리케이션을 유지하기위한

- 하위 디렉토리(classes, lib, web.xml)로 구성되어있다.

webapp

- context path, WAS에서 웹 애플리케이션을 구분하는 경로

- 웹 애플리케이션 구동 시, localhost:포트번호/뒤에 나오는 명칭

- 타 웹 어플리케이션과 중복을 허용하지 않는다.

 

WEB-INF

- 웹 애플리케이션에 관한 정보가 저장되는 위치

- 해당 디렉토리는 외부에서 접근이 불가하다.

 

 

 

동작

- 웹 애플리케이션은 자바 프로그램처럼 단독으로 동작할 수 없다.

- 웹 애플리케이션은 웹 컨테이너에서 실행되는 구조로서 톰캣에 등록하여 사용해야한다.

- 가장 대표적인 등록 방식은 server.xml에 컨텍스트를 등록하는 방식이다.

---

 

# Web Application Model

- 웹 어플리케이션 개발 시, 일반적으로 화면은 디자이너가 맡으며 DB연동 및 기능은 개발자가 구현한다.

- 개발 시간을 단축시키기위해서 가장 표준화된 소스 구조를 사용하는데 이를 웹 어플리케이션 모델이라고 부른다.

- 대표적으로 모델1 / 모델2 방식이 존재한다.

 

 

(1) Model 1

- 서블릿없이 Jsp에서 화면부터 DB작업까지 전부 처리하는 형태

- 비즈니스 로직 작업 (DB 연동) 과 작업 결과를 나타내주는 작업을 동일한 Jsp에서 처리한다.

- (모든 클라이언트의 요청과 비즈니스 로직 처리를 Jsp에서 담당)

- 기능 구현이 쉽고 편리하다는 장점이 있으나 웹사이트가 복잡해지면 유지보수가 어렵다는 단점이 있다.

 

 

(2) Model 2

- 웹 애플리케이션의 각 기능 (클라이언트의 요청 처리 / 응답 처리 / 비즈니스 로직 처리) 을 분리하여 구현

- 화면 구현(Jsp)과 처리 로직(서블릿)을 분리하여 작업하는 형태

- 각 기능이 모듈화되어있어 각 모듈의 재사용성이 높다.

- MVC (Model-View-Controller) 디자인 패턴이라고도 부른다.

 

# 1 Controller	# 2 Model	# 3 View
사용자의 요청 및 흐름 제어를 담당	비즈니스 로직 처리	사용자에게 보여주는 화면
- 클라이언트의 요청 분석 - 요청에 대해서 필요한 모델을 호출	- DB연동과 같은 비즈니스 로직 수행 - 일반적으로 Dao와 VO클래스로 구성	- Jsp가 화면 기능 담당 - Model에서 처리한 결과를 화면에 표시

 

 

MVC 구성 요소 및 동작 과정

동작 과정

(1) 사용자가 url를 통해서 특정 작업 요청

(2) 화면을 통해서 요청이 Dispatcher Servlet로 전달

• Dispatcher Servlet은 사용자의 요청을 처리하는 MVC의 핵심 요소이다.
• 사용자의 요청을 처음으로 받아 처리하므로 front controller라고도 부른다.
• 맵핑에따라 적절한 컨트롤러에게 요청을 전달하고 컨트롤러가 리턴할 값을 view에 전달하여 적절한 응답을 하도록 한다.
• web.xml에 등록하여 사용한다.

 

(3) 사용자의 요청 URL(.do를 매핑한 컨트롤러가 있는지 Handler Mapping에서 검색

• Handler Mapping은 사용자의 요청 url이 맵핑된 컨트롤러로 넘겨주는 역할을 하는 인터페이스이다.
• (클라이언트가 요청한 url을 처리할 컨트롤러 지정)
• @RequestMapping 어노테이션으로 맵핑 url를 검색한다.
• 서블릿설정 파일에 존재한다.

 

(4) Servlet-Context.xml에 있는 등록된 Bean객체로 컨트롤러내의 맵핑 url에 연결된다.

(5) Service, Dao, Mapper의 동작

• Service : 사용자의 요청을 처리 (인터페이스와 구현 클래스로 Service, ServiceImpl 형태로 사용)
• Dao : DB와 관련된 crud 작업의 로직 분리 (인터페이스로 맵퍼 쿼리를 id명칭으로 분류한다.)
• Mapper : 쿼리 (Dao에서 관리되는 쿼리의 집합으로 id로 구분된다.)

 

(6) DB 작업

(7) 처리한 결과를 가지고 역순으로 컨트롤러로 복귀

(8)요청을 처리한 뒤 결과를 출력할 화면 (View)의 명칭이 담긴 ModelAndView에 저장하여 Dispatcher Servlet으로 리턴

(9) View의 명칭을 View Resolver로 전달하여 검색

• View Resolver는 컨트롤러에서 넘겨준 View가 어떤 것인지 검색한다.
• View 명칭이 존재하는 경우 처리 결과를 검색한 View로 전달한다.

 

(10) 처리 결과를 View로 전달

(11) 처리 결과가 포함된 화면(View)을 Dispatcher Servlet로 전송

(12) 최종 결과를 사용자에게 출력

 

[참고] 기본적으로 web.xml에 한가지 이상의 Dispatcher Servlet을 설정한다.

---

 

 

# Service & Dao

- Dao : 서버에 접근하는 기능을 수행

- Service : 실제 프로그램을 업무에 적용하는 사용자 입장의 업무 단위 (트랜젝션)

서비스를 사용하는 모델2에서는
한가지의 단위 기능 (서비스) 에  여러 Dao의 다양한 Sql문을 묶어서 수행하는 경우가 많다. 

서비스 클래스의 메소드를 이용하여 큰 기능을 단위 기능으로 나눈 후
서비스 내의 각 메소드가 해당 기능을 세부적인 기능을 수행하는 Dao의 Sql문으로 조합하여 서비스 메소드를 구현한다.

필요한 단위 기능에서 필요한 여러 쿼리문을 독립적으로 조합하여 사용할 수 있으므로 
이는 유지보수, 시스템의 확장성 면에서 효율적이다.

 

 

 

[참고] Service, Dao의 Impl 사용 이유

- 다중 상속이 가능한 인터페이스를 활용하여 코드의 범용성을 높이기 위함에 있다.

위 사진처럼 Dao에서 Oracle방식에서 Mysql의 방식으로 변경해야하는 경우
인터페이스의 다중 상속을 활용하여 Oracle 클래스를 수정하지 않고 Mysql 클래스를 구현한 뒤
Dao (인터페이스)에서 Mysql로 변경하여 사용하면 된다.

이는 클래스간의 의존 관계를 약하게 만드는 장점이 있다.
(단, Impl클래스 자체는 소스 상에서 직접 수정해야한다.)