ch15. 간단한 웹 어플리케이션 구조

1. [간단한 웹 어플리케이션 구성 요소]

[프론트 서블릿] [컨트롤러 + 뷰] [서비스] [DAO]

▶[프론트 서블릿] : 요청 받는 창구

-웹 브라우저의 모든 요청 받는 창구 역할

-스프링 MVC에서는 DispatcherServlet = 프론트 서블릿 역할 수행

-웹 브라우저의 요청 분석 후 -> 알맞은 컨트롤러에 전달

▶[컨트롤러 + 뷰] : 기능을 실행 -> 결과 전달

-웹 브라우저가 요구한 기능 실행 -응답 결과 생성에 필요한 모델 생성 -응답 결과 생성할 뷰 선택

-컨트롤러는 웹 브라우저의 요청을 처리에 알맞은 기능을 실행 후 그 결과를 뷰에 전달

▶[서비스] : 실질적 기능 자체

-기능 로직을 구현함

-실질적으로 기능 제공 위한 로직을 직접 수행

-핵심 로직

-기능에 DB 연동 필요하면 DAO 사용 (Data Access Object)

-[DAO] : DB와 웹 어플리케이션 간의 데이터 이동 역할 -웹 어플리케이션은 DAO를 통해서 DB에 데이터 추가/가져옴

---

2. [서비스 클래스 구현]

<ex. 회원 비번 변경 기능 제공 > ➀ DB에서 비번 변경할 회원 데이터 가져옴 (없으면 익셉션) ➁ 회원 데이터의 비번 변경 ➂ 변경 내역을 다시 DB에 반영

-핵심이 되는 기능의 로직 제공

> 서비스 메소드는 트랜잭션 범위에서 실행함

▶기본적으로 각 서비스 클래스는 기능 제공을 위해 한 개의 public 메소드 제공

▶같은 데이터 사용 기능들을 한 개의 서비스 클래스에 모아 구현할 수도 O

ex. 회원 가입 기능 제공      서비스 메소드는 파라미터로 기능에 필요한 데이터를 받아야 하는데, ▶필요한 데이터만 담고 있는 별도의 클래스를 만들고 파라미터로 사용할 수도 O -> 컨트롤러 클래스는 이 별도의 클래스를 커맨드 객체로 사용 ▶웹 요청 파라미터를 커맨드 객체로 받은 뒤, 그 커맨드 객체를 서비스 메소드에 전달 O

<커맨드 객체 사용 이유> 폼 값 바인딩/검증 , 스프링 폼 태그와의 연동 기능 수행 목적

<서비스 메소드 기능 실행 결과> 정상 결과 : 리턴값 비정상 결과 : 익셉션 발생 (-> 이 익셉션은 컨트롤러 클래스 안에서 에러 처리)

---

3. [컨트롤러에서의 DAO 접근]

-서비스 메소드에서 단순히 DAO만 호출한 경우도 있다.   예) 회원 데이터 조회 위한 서비스 메소드 작성

-컨트롤러는 이 서비스 메소드가 반환한 것을 이용해도 되지만, 직접 DAO 접근하여 회원 정보를 구해도 된다.

---

4. [패키지 구성]

▶웹 요청 처리 영역 : 컨트롤러/커맨드/Validator ▶기능 제공 영역 :서비스/DAO/Member(모델 클래스)            -> 기능 제공 영역을 다시 세부 패키지로 구분O