본문 바로가기

공부/스스로

Spring MVC

Spring mvc, 어노테이션 등등 정리 잘되있음

https://min-it.tistory.com/7 

 

[06] Spring MVC - 모델2 스프링 MVC 개념과 DispatcherServlet

안녕하세요. MIN-IT입니다. 이번시간은 Spring MVC과 DispatcherServlet 대해 공부해보겠습니다.. 퍼가실 때 댓글을 남겨주시면 감사하겠습니다. http://min-it.tistory.com 스프링 MVC는 모델 2방식 구조입니다...

min-it.tistory.com

 

1. 클라이언트(사용자)의 모든 요청은 DispatcherServlet이 받는다.

2. DispatcherServlet은 hanlderMapping을 통해서 요청에 해당하는 Controller를 실행 시킨다.

3. Controller는 적절한 서비스 객체를 호출 시킨다.

4. Service는 DB처리를 위해  DAO를 이용하여 데이터를 요청 한다.

5.DAO는 mybatis를 이용하는 Mapper를 통해 작업 처리를 한다.

6. 결과(처리한 데이터)가 mapper->DAO->Service->Controller로 전달된다.

7. Contorller는 전달된 결과(처리된 데이터)를 View Resolver를 통해 전달 받을 View가 있는지 검색한다.

8. 전달 받은 View가 있다면 View에게 전달된 결과(처리된 데이터)를 전달한다.

9. View는 전달받은 결과(처리된 데이터)를 다시 DispatcherServlet에게 전달한다.

10. DispatcherServlet은 전달받은 결과(처리된 데이터)를 클라이언트에게 전달한다

 

Controller => Service => DAO => mappter => DAO => Service => Controller => View(데이터전달) => 클라이언트.

 

*Front Controller의 역할은 서버로 들어오는 모든 요청을 받아서 처리합니다.

(공통 처리 작업을 먼저 수행 한 후 적절한 세부컨트롤러에게 작업을 위임해주고 예외 발생시 일관된 방식으로 에러를 처리해주는 일을 합니다.

이런 일들을 하기 때문에 각 컨트롤러들 사이의 중복된 코드 문제나

협업시 개발자들의 개발 방식이 다른 경우 등을 해결을 할 수 있습니다.)

 

*스프링에서 제공하는 FrontController인 DispatcherServlet의 역할은 무엇일까요??

DispatcherServlet의 등장으로 엄청나게 web.xml의 역할이 축소 된 것입니다.

DispatcherServlet가 있기전에는 사용자의 URL을 일일이 요청을 처리하기 위해

web.xml에 등록(서블릿과 매핑시켜주는 작업)을 반드시 해야했었습니다.

그렇다고 web.xml이 안쓰이는 것은 아닙니다.

web.xml에서 자주 쓰이는 서블릿 매핑을 DispatcherServlet이 한다고 생각하시면 되고

나머지 web.xml의 기능들은 그대로 web.xml을 이용하신다고 생각하시면됩니다.

(web.xml의 기능은 DispatcherServlet등록, 객체의 URL범위 , 필터 등이 있습니다.)

 

 

*스프링 MVC Controller의 특징

 

1. 파라미터 수집

-사용자의 요청에 필요한 데이터를 추출하고

VO(DB의 레코드와 상응되는 클래스) 나 DTO(컨트롤러,뷰,비즈니스등의 계층간 데이터 교환을 위한 자바빈즈)로 변환하는 파라미터의 수집 작업을 합니다.

 

2.애노테이션을 통한 간편 설정

-스프링 MVC 설정은 MVC나 애노테이션을 사용가능하고, 주로 애노테이션을 이용하여 클래스나 메소드의 선언에 필요한 애노테이션을 추가하는 작업을 통해 요청이나 응답에 필요한 모든 처리를 완료할 수 있습니다.

 

3.테스트의 편리

-WAS의 실행없이도 테스트할 수 있는 편리한 방법을 제공



 

 

출처 : nickjoit.tistory.com/9

Model : 프로그램의 내부 상태, 즉 프로그램의 정보(데이터)

Controller : 데이터와 비즈니스 로직 간의 상호 작용

View : 사용자 인터페이스 요소. UI 화면

 

 

 MVC 1 

- JSP로 구현한 기존 웹 어플리케이션은 모델 1 구조로 웹 브라우저의 요청을 JSP 페이지가 받아서 처리

- JSP 페이지에 비지니스 로직을 처리 하기 위한 코드 +  웹 브라우저에 결과를 보여주기 위한 출력 관리 코드 뒤섞여 있음

- JSP 페이지 안에서 모든 정보를 표현(view)하고 저장(model)하고 처리(control)되므로

  재사용이 힘들고, 읽기도 힘들어 가독성이 떨어진다.

- 정의: 모든 클라이언트 요청과 응답을 JSP가 담당하는 구조

- 장점: 단순한 페이지 작성으로 쉽개 구현 가능하다. 중소형 프로젝트에 적합

- 단점: 웹 애플리케이션이 복잡해지면 유지보수 문제가 발생된다.

 

MVC 2 

 

- MVC1 구조와 달리 웹 브라우저의 요청을 하나의 서블릿이 받게 됨

- 서블릿은 웹 브라우저의 요청을 알맞게 처리한 후 그 결과를 JSP 페이지로 포워딩

- 정의: 클라이언트의 요청처리와 응답처리, 비지니스 로직 처리하는 부분을 모듈화시킨 구조

- 장점: 처리작업의 분리로 인해 유지보수와 확장이 용이하다.

- 단점: 구조 설계를 위한 시간이 많이 소요되므로 개발 기간이 증가한다.

 

 스프링 MVC 프레임워크 

- 스프링이 제공하는 트랜잭션 처리, DI, AOP를 손쉽게 사용

- 스트럿츠2와 같은 프레임워크와 연동이 쉬움