[Spring] Spring MVC 구조

🌼 스프링 

• 스프링 프레임워크
• Frame(틀)안에서 work(동작)하는것을 뜻함. 개발할때 틀을 벗어나지말고 틀안에서만 개발하는것에 의미를 둠
• 동적인 웹 사이트를 개발하기 위한 여러 가지 서비스를 제공
• 스프링 프레임워크의 구성은 20여가지로 구성되며 이러한 모듈들은 스프링의 핵심기능(DI, AOP, etc)을 제공해주며, 필요한 모듈만 선택하여 사용가능
• 여러가지 모듈이 있지만 그중에서 단연 스프링붙, 스프링 클라우드, 스프링 데이터, 스프링 배치, 스프링 시큐리티에 중점을 둠
• 라이브러리는 개발자가 직접 프로그램의 흐름을 결정하지만 프레임워크는 정해진 흐름에 맞게 개발자가 프로그램을 개발한다. 

 

🌷 Spring MVC 구조

• 스프링 프레임워크는 MVC 구조로 이루어져있다.
• MVC = Model - View - Controller
• 스프링 모델은 View - Controller - Service - DAO  - DB 로 이루어져있다. 

 

스프링 모델

 

• View(Browser)
  말 그대로 사용자에게 보여지는 화면을 View라고 한다. Spring에서는 JSP를 통해 화면을 구성하고 Controller를 통해 백엔드 서버와 연결한다.
• Controller
  View와 Service 사이를 연결한다. 클라이언트에서 입력한 URL에 맞는 View를 보여주고, View에서 처리하는 데이터를 Service로 전달해준다.
• Service
  실제 로직을 처리하는 곳으로 사용자의 요청을 처리하며 모든 기능은 Service에서 만들어진다. Controller를 통해 화면과 연결되고, DB 정보가 필요할때는 DAO를 통해 데이터베이스와 연결된다. 
• DAO
  Data Access Object의 줄임말인 DAO는 프로젝트와 데이터베이스를 연결한다. 직접 DB에 접근하여 데이터를 삽입 / 삭제 / 조회 등 조작할 수 있는 기능 수행하며 DB 접근을 하기 위한 로직과 비지니스 로직을 분리한다. Mapper에 SQL을 명시한뒤 Mapper와 함께 데이터베이스와 데이터를 주고받는다.
• DTO
  계층간 (Controller, View, Business Layer) 데이터 교환을 위한 자바빈즈이며 DB의 데이터를 Service나 Controller 등으로 보낼 때 사용하는 객체이다. DB의 데이터가 Presentation Logic Tier로 넘어올때는 DTO로 변환되어 오고가며 DTO는 로직을 가지지 않고  getter/setter 메소드만 가진 순수한 데이터 객체이다.
  ▶ DTO와 VO가 완벽하게 같은 말은 아니지만 크게 차이를 두진 않는다
• Entity
  실제 데이터베이스와 1:1 매칭되는 클래스이며 DB 테이블 내 존재하는 컬럼만을 속성 (필드)로 가져야 한다. 테이블 내에 존재하지 않는 컬럼을 가져도 안되며 상속받거나 구현 클래스여도 안된다. 최대한 외부에서 Entity 클래스의 getter/setter를 사용하지 않도록 클래스 내부에서 필요한 로직을 구현해야 한다. 구현 메소드는 주로 Service Layer에서 사용한다.또한  Presentation Logic을 가지면 안된다.

 

 

⭐ Dispatcher-Servlet

• dispatch는 "보내다".
• 이러한 단어를 포함하는 디스패처 서블릿은 HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임함.
• 클라이언트로부터 어떠한 요청이 오면 Tomcat(톰캣)과 같은 서블릿 컨테이너가 요청을 받는다. 그리고 이 모든 요청을 프론트 컨트롤러인 디스패처 서블릿이 가장 먼저 받으며 디스패처 서블릿은 공통적인 작업을 먼저 처리한 후에 해당 요청을 처리해야 하는 컨트롤러를 찾아서 작업을 위임한다.
• 여기서 Front Controller(프론트 컨트롤러)라는 용어가 사용되는데, Front Controller는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 처리해주는 컨트롤러로써, MVC 구조에서 함께 사용되는 디자인 패턴이다.
• 과거에는 모든 서블릿을 URL 매핑을 위해 web.xml에 모두 등록해주어야 했지만, dispatcher-servlet이 해당 어플리케이션으로 들어오는 모든 요청을 핸들링해주고 공통 작업을 처리면서 상당히 편리하게 이용할 수 있게 되었다. 우리는 컨트롤러를 구현해두기만 하면 디스패처 서블릿가 알아서 적합한 컨트롤러로 위임을 해주게 된다. 출처:  https://mangkyu.tistory.com/18 [MangKyu's Diary:티스토리]

1. 사용자 요청 전송을 하면 DispatcherServlet 이 요청을 가로챔
     web.xml에 `<url-pattern>/</url-pattern>` 등록된 내용 가로챔
2.  DispatcherServlet 이 가로챈 요청을 HandlerMapping 에게 보냄
3.  HandlerMapping은 사용자 요청을 처리할 수 있는 Controller 검색
4. DispatcherServlet은 선택된 Controller 비지니스 로직 실행을 HandlerAdapter에게 위임
5. HandlerAdapter가 Controller의 비지니스 로직 호출
6. 비지니스 로직 호출 결과를 Model 이나 ModelAndView 객체에 담아서 DispatcherServlet에게 반환함
7. DispatcherServlet이 ViewResolver를 이용하여 결과를 보여줄 View를 검색
8. 처리 결과가 포함된 View 객체를 DispatcherServlet에 송신하여 최종 결과를 출력함

 

 

⭐ 스프링 웹 계층

 

 

Presentation Layer

• 브라우저 상의 웹 클라이언트 요청 및 응답 처리
• 사용자 요청에 맞는 @Controller를 호출
• 사용자 요청 객체에 대한 유효성 처리
• Business Layer 나 Persistence Layer에서 발생하는 예외처리
• Controller, View 포함

 

Business Layer

• Service Layer
• 실제 비지니스 로직을 수행하는 컴포넌트
• Presentation Layer에서 들어오는 사용자 요청 데이터가 아니라 다른 계층을 통해 들어왔거나 Controller를 직접적으로 거치지 않는 요청일 경우 해당 계층에서 처리
• 모든 인터페이스에 핵심 API로 제공하려면 Service Layer에서 UI specific하다면 Presentation Layer 처리
• 외부 API 사용할 경우 해당 계층에서 사용
• 공통적으로 사용해야하는 작업이 있다면 해당 계층에서 처리
• 컨트롤러에서 요청을 보내면 DAO를 이용해 실제 비지니스 로직을 수행
• DAO에서 받은 데이터 Entity의 유효성을 확인하고 DTO로 변환
• Persistence Layer와 Presentation Layer이 직접적으로 통신하지 않게 함
• 직접적으로 통신할 경우 Persistence Layer의 데이터가 수정될 수 있음을 막기 위함
• 트랜잭션 관리
• Service 인터페이스와 @Service 클래스

 

Persistence Layer

• Repository Layer / Data Access Layer
• DB에 값을 저장하거나 가져오기 위해 SQL 질의 및 수행 결과를 전달
• DB에 데이터를 CRUD (Create, Read, Update, Drop)하는 계층
• DAO 인터페이스와 @Repository 클래스

 

계층을 나누는 것의 장점

• 관심 분리를 통해 대상 계층에 집중 가능
• 계층을 나누면서 모듈화하게 되므로 모듈 갈아 끼우기 가능
• 계층별 테스트가 쉬워짐

 

계층 나누는 방법

• 도메인을 먼저 분리함
  • naver
    • pay
    • shopping
    • news
• 각 도메인 안에서 Presentation - Business - Persistence로 나누는 것이 좋음