Spring MVC
3계층 아키텍쳐
웹 애플리케이션을 개발할 때 디자인 패턴은 MVC 디자인 패턴을 사용하며, 구조적인 측면에서 3계층 아키텍처를 사용한다. 각 레이어는 독립된 역할을 갖는다.
- 정의
- 프레젠테이션 계층(Presentation tier/Layer)
- 구성 : 뷰, 컨트롤러
- 최상위에 위치하는 영역으로써, 사용자와 애플리케이션 간 상호작용 위한 인터페이스, 사용자의 요청을 비즈니스 계층에 전달하거나, 처리 결과를 뷰 페이지로 이동하는 기능
- 프런트엔드
- 비즈니스 계층(Business tier) = 서비스 영역(Business Logic Layer)
- 실제 클라이언트가 요청한 서비스를 처리하는 비즈니스 로직 구현
- 미들웨어, 백엔드
- 영속 계층(Persistent tier) = 데이터 영역(Data Access Layer)
- 데이터베이스 서버나 파일 시스템에 접근하여 데이터를 생성/관리하는 기능 담당
- 백엔드
- 프레젠테이션 계층(Presentation tier/Layer)
DAO와 DTO의 차이
DAO(Data Access Object)
DB의 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 객체를 말한다.
DB에 접근을 하기 위한 로직과 비즈니스 로직을 분리하기 위해서 사용
DTO(Data Transfer Object)
계층 간 데이터 교환을 위한 객체를 말한다.
여기서 말하는 계층은 Controller, View, Business Layer, Persistent Layer 이다.
일반적인 DTO는 로직을 갖고 있지 않는 순수한 데이터 객체이며, 속성과 그 속성에 접근하기 위한 getter, setter 메소드만 가진 클래스이다.
VO(Value Object)
- DTO와 동일한 개념이지만 read only 속성을 가진다.
MVC 패턴
- 정의
- 애플리케이션을 모델(Model), 뷰(View), 컨트롤러(Controller) 로 구분하여 작업을 분리하는 디자인 패턴
- 구분
- 뷰
- 클라이언트와 서버 간의 인터페이스 역할을 하는 영역으로서 클라이언트로부터 요청 받거나 처리된 결과를 보여주는 기능
- 구현 방법 : HTML, CSS, JSP
- 컨트롤러
- 뷰와 모델을 연결하는 중계 역할. 클라이언트가 전달한 파라미터를 추출하여 모델로 전달하고, 처리 결과를 페이지로 보여주는 기능
- 구현 방법 : JSP, 서블렛
- 모델
- 서비스와 데이터베이스 처리를 담당하는 역할. 비즈니스 로직 처리, DB 질의 처리 기능
- 구현 방법 : POJO(Plain Old Java Object). 일반 평범한 자바 객체
- 구분
- Service/Business 객체 : 서비스 처리 담당.
- DAO(Data Access Object) : 데이터베이스 처리 담당.
- 뷰
- 장점
- 서로 간의 결합도를 최소화
- 유지보수성 높임
- 개발자들이 각각 맡은 영역에만 집중할 수 있게 하여 개발의 효율성을 극대화
프런트 컨트롤러 디자인 패턴
대표 컨트롤러(Front Controller)을 두고 뷰에서 들어오는 모든 요청을 담당하게 하여 애플리케이션을 실행하는 모든 요청을 일괄적으로 처리.
- 프런트 컨트롤러 구현 방법
- 프런트 컨트롤러 지정 및 URL 패턴 지정 : web.xml에 서블렛으로 FrontController 및 url-pattern 으로 /*을 설정하여 모든 요청을 받을 수 있게 한다.
- 그 후 실제 요청한 서비스를 처리할 서브 컨트롤러를 구현한다.
- 프런트 컨트롤러 기능
- 어떤 컨트롤러가 요청을 실행할 지 결정
- 렌더링할 뷰를 결정
- 장점
- 각 요청을 적절한 곳으로 위임해줌으로써 개발과 유지보수의 효율성이 증가
- 모든 요청에 대해 보안, 국제화, 라우팅 및 로그와 같은 일반적인 기능을 한 곳에서 캡슐화
스프링 프론트 컨트롤러 패턴
디스패처 서블릿(Dispacher Servlet)이 web.xml에 설정되어 클라이언트로부터의 모든 요청을 받는다. 어떠한 요청이 들어왔을 때 적절한 Handler Method에 요청을 전달하고, 리턴한 결과값을 뷰에게 전달하여 알맞은 응답을 생성한 후 클라이언트에게 보낸다.
Spring MVC 애플리케이션 설정법
- 스프링 MVC 의존 관계 추가
- spring-webmvc
- web.xml에 디스패쳐 서블릿 추가
- 서블렛으로 디스패쳐 서블릿 및 url-pattern 으로 "/*"을 설정하여 모든 요청을 받을 수 있게 한다.
- Spring Bean Configuration 파일(beans-web.xml) 설정
- default-servlet-handler 설정
- DispatcherServlet은 url pattern 을 "/" 와 같이 설정하게 되면서 tomcat 의 web.xml 에 정의되어 있는 url pattern "/" 을 무시하게 된다. 결국 DispatcherServlet url pattern 을 재정의하게 되어서 DefaultServlet 은 더 이상 동작할 수 없게 된 것이다. Spring에서는 이를 해결하기 위해서 <mvc:default servlet handler /> 설정을 지원한다.
- annotation driven 태그 설정
- <mvc:annotation-driven />
- Spring MVC에 필요한 Bean 들을 자동으로 등록해주는 태그
- default-servlet-handler 설정
- 스프링 컨텍스트 설정
- 컴포넌트 스캔으로 package를 scan하고 패키지 내 @Bean, @Controller, @RestController 애노테이션 등의 어노테이션을 확인하여 빈과 컨트롤러가 생성되고 오토와이어링 된다.
Spring MVC의 주요 구성 요소
- Dispatcher Servlet : 어떠한 요청이 들어왔을 때 적절한 Handler Method에 요청을 전달하고, 리턴한 결과값을 뷰에게 전달하여 알맞은 응답을 생성한 후 클라이언트에게 보낸다.
- HanderMapping : URL과 요청 정보를 기준으로 어떤 핸들러 메소드를 사용할 지 결정하는 객체이며, 디스패처 서블릿은 하나 이상의 핸들러 매핑을 가질 수 있다.
- Controller : 클라이언트의 요청을 처리한 뒤, Model을 호출하고 그 결과를 디스패처 서블릿에게 알려 줌.
- ModelAndView : 컨트롤러가 처리한 데이터 및 화면에 대한 정보를 보유한 객체
- View : 컨트롤러의 처리 결과 화면에 대한 정보를 보유한 객체
- ViewResolver : 컨트롤러가 리턴한 뷰 이름을 기반으로 컨트롤러 처리 결과를 생성할 뷰를 결정
스프링 프론트 컨트롤러 패턴 실행 흐름
- 클라이언트(Client)가 서버에 어떤 요청(Request)을 한다면 스프링에서 제공하는 DispatcherServlet 이라는 클래스(일종의 front controller)가 요청을 가로챈다.
(web.xml에 살펴보면 모든 url ( / )에 서블릿 매핑을하여 모든 요청을 DispatcherServlet이 가로채게 해둠(변경 가능))
- 요청을 가로챈 DispatcherServlet은 HandlerMapping(URL 분석등..)에게 어떤 컨트롤러에게 요청을 위임하면 좋을지 물어본다.
(HandlerMapping은 servlet-context.xml에서 @Controller로 등록한 것들을 스캔해서 찾아놨기 때문에 어느 컨트롤러에게 요청을 위임해야할지 알고 있다.)
요청에 매핑된 컨트롤러가 있다면 @RequestMapping을 통하여 요청을 처리할 메서드에 도달한다.
컨트롤러에서는 해당 요청을 처리할 Service를 주입(DI)받아 비즈니스 로직을 Service에게 위임한다.
Service에서는 요청에 필요한 작업 대부분(코딩)을 담당하며 데이터베이스에 접근이 필요하면 DAO를 주입받아 DB처리는 DAO에게 위임한다.
DAO는 mybatis(또는 hibernate등) 설정을 이용해서 SQL 쿼리를 날려 DB에 저장되어있는 정보를 받아 서비스에게 다시 돌려준다.
(이 때, 보통 Request와 함께 날아온 DTO 객체(@RequestParam, @RequestBody, ...)로 부터 DB 조회에 필요한 데이터를 받아와 쿼리를 만들어 보내고, 결과로 받은 Entity 객체를 가지고 Response에 필요한 DTO객체로 변환한다.)
모든 비즈니스 로직을 끝낸 서비스가 결과물을 컨트롤러에게 넘긴다.
결과물을 받은 컨트롤러는 필요에 따라 Model 객체에 결과물 넣거나, 어떤 view(jsp)파일을 보여줄 것인지등의 정보를 담아 DispatcherServlet에게 보낸다.
DispatcherServlet은 ViewResolver에게 받은 뷰의 대한 정보를 넘긴다.
ViewResolver는 해당 JSP를 찾아서(응답할 View를 찾음) DispatcherServlet에게 알려준다.
(servlet-context.xml에서 suffix, prefix를 통해 /WEB-INF/views/index.jsp 이렇게 만들어주는 것도 ViewResolver)
DispatcherServlet은 응답할 View에게 Render를 지시하고 View는 응답 로직을 처리한다.
결과적으로 DispatcherServlet이 클라이언트에게 렌더링된 View를 응답한다.
컨트롤러를 위한 핵심 어노테이션
- @RequestMapping : HTTP 요청 URL을 처리할 컨트롤러 클래스 또는 메소드 정의. 메소드를 특정 요청 메소드(GET, POST 등)에 매핑할 수 있다.
- @RequestParam : HTTP 요청에 포함된 파라미터 참조 시 사용
- @ModelAttribute : HTTP 요청에 포함된 파라미터를 모델 객체로 바인딩
- @PathVariable : 파라미터를 URL 형식으로 받을 수 있게 해 줌
@ExceptionHandler 어노테이션의 사용
- 컨트롤러의 메서드에 ExceptionHandler 어노테이션을 설정하여 컨트롤러의 메서드에서 예외가 발생했을 때 예외 처리를 할 수 있음.
- 예외가 발생했을 때 예외 Type 과 Message 를 보여주는 JSP 페이지를 작성해야 함.
REST
RESTful 웹서비스
- ROA(Resource Oriented Architecture) 개념을 실현하기 위한 리소스 중심의 표현, 전달, 접근 방식의 기술.
- REST(Representational State Transfer) 기반의 웹 서비스로서, HTTP의 기본 기능만으로 원격 정보에 접근 가능.
- REST : HTTP URI + HTTP Method
- HTTP URI를 통해 제어할 자원(Resource)을 명시하고, HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 자원을 제어하는 명령을 내리는 방식의 아키텍쳐
- REST : HTTP URI + HTTP Method
- 서버와 클라이언트로만 분리되어 있다.
- 클라이언트에서 XML, JSON, 텍스트, 이미지 등 원하는 형식으로 표현 가능
- 이러한 표현 형식은 HTTP의 accept 헤더 값이나 URI 파라미터로 지정
Spring MVC 기반 RESTful 웹서비스 구현 절차
- RESTful 웹서비스를 처리할 RestfulController 클래스 작성 및 @RestController 어노테이션(@ResponseBody + @Controller) 선언하여 Bean으로 등록
- 요청을 처리할 메서드에 @RequestMapping, @RequestBody, @ResponseBody 어노테이션 선언
RESTful Controller를 위한 핵심 어노테이션
- 스프링 MVC에서는 클라이언트에서 전송한 XML이나 JSON 데이터를 컨트롤러에서 자바 객체로 변환해서 수신할 수 있다.
- @RequestBody : HTTP Request Body(요청 몸체)를 자바 객체로 전달 받을 수 있다.
- 자바 객체를 XML이나 JSON으로 변환해서 송신할 수 있다.
- @ResponseBody : 자바 객체를 HTTP Request Body(응답 몸체)로 전송할 수 있다.
Reference
'Web_Backend > Spring' 카테고리의 다른 글
6.Spring 개념 기타 (1) | 2024.07.12 |
---|---|
5.SpringBoot (0) | 2024.07.12 |
3.Spring AOP (0) | 2024.07.12 |
2.Spring DI (0) | 2024.07.12 |
1.Spring Framework와 IoC (0) | 2024.07.12 |