Servlet 방식과 Spring 에서의 웹 개발

서블릿(Servlet)

서블릿을 통한 웹 페이지 구현

• 서블릿은 동적 웹 페이지를 만들 때 사용되는 자바 기반의 웹 어플리케이션 프로그래밍 기술이다.
• 동적으로 웹 페이지를 생성하기 위해서 서블릿은 요청(request)을 받으면 해당 요청에 맞는 서블릿을 찾은 뒤, 로직을 처리하고 이를 html 페이지로 생성하여 보여주는 동작을 수행한다.
• 이때 html 페이지를 생성하기 위해서는 직접 자바 코드로 html코드를 입력해주어야 했기 떄문에, context check나 가독성 면에서 매우 좋지 않았다고 한다.

 

JSP의 출현

• html코드를 자바 프로그래밍을 통해 하는 것은 매우 고된 일이었기 때문에 방법을 찾다가 JSP(Java Server Page)라는 것이 출현하였다.
• 해당 방식은 html 문서 내부에 자바 프로그래밍 코드를 넣을 수 있도록 하면서 서블릿 방식과는 정 반대로된 방식이었다. 여기서부터 모델 1이라는 디자인 패턴이 생겨났다.

• 모델 1은 JSP에서 모든 동작을 수행했다. 여기서 모든 동작이란 것은 말 그대로, 요청을 받고, 비즈니스 로직을 처리한 뒤 변경이 있을 경우, DB에 해당 변경점을 갱신하거나 DB에서 데이터를 찾아 로직을 처리하는 동작들이다.
• 이런 데이터 가공과, DB에서 데이터를 찾거나, 갱신, 삭제의 동작들을 하나의 JSP로 처리했기 때문에 그 구조가 매우 난잡했으며, 동시에 가독성도 매우 떨어졌다.
• 구조의 복잡함과 가독성의 문제는 곧 프로젝트가 커질수록 생산성의 저하로 나타나게 되었다. 그래서 그 다음에 나온 구조가 모델 2 구조였다. 

• 모델 2 구조는 각 요청을 받아두고, 가공한 뒤 View에 제공하는 Controller, 화면을 보여주는 View, 데이터를 가져오거나, 비즈니스 로직(주 기능)을 수행하는 Model의 개념을 사용하였다.
• 특정한 url을 통해 request가 서버에 들어올 시, 서버는 자신이 가지고 있는 Controller(java 에서는 Servlet으로, url-pattern과 매칭되는 Servlet이 곧 그 request를 받는 Controller가 된다.)중 매칭되는 것이 존재하는지 확인한다.
• 만약 존재한다면 해당 Controller로 requset를 넘긴다. Controller는 만약 Model에서 데이터를 처리하여야 할 경우 Model을 부르고(역시 Servlet)해당 모델에 request에서 받은 데이터를 넘긴다.
• Model은 넘겨받은 데이터를 자신의 비즈니스 로직에 맞게 처리한다. 이때 DB에 갱신해야 할 경우나, DB에서 데이터를 찾아와야 할 경우, DB와 통신한다.
• 이후 처리된 데이터를 다시 컨트롤러에게 넘겨주면, 컨트롤러는 처리된 데이터를 받아 View에 Response로 넘겨준다.
  • Servlet에서는 일반적으로 getRequestDistpatcher의 foward를 통해 데이터를 넘긴다.
• 이후 View(JSP 파일)은 컨트롤러에서 받은 데이터를 사용자에게 보여주는 역할을 한다.

 

 

 

MVC 패턴 디자인

• 위의 모델 2 방식을 MVC패턴으로 부른다. 각 영역에 대해 대응되는 Controller가 존재하고, 이 Controller는 자신이 View에 데이터를 전달하기 위해 필요한 Model 기능들을 호출한다.
• Model은 각각 구현된 기능을 통하여 데이터를 처리하고, 이 데이터를 다시 컨트롤러에 반환한다. 각각의 개념에 대해 역할이 명확하고 잘 나누어질 수 있음을 볼 수 있다.
• 이렇게 될 경우 JSP에서는 로직을 수행할 필요 없이 받은 데이터를 그대로 출력하기만 하면 되기 때문에, java코드 자체가 매우 줄어들며 그에 따라 html문서의 가독성 역시 증가하게 된다.
• 현재는 이 Model 2 방식에서 조금 더 발전된 MVC 패턴을 사용하는데 구조는 아래와 같다.

• Model에서 비즈니스 로직과 DB 접근을 동시에 하던 Model 2와는 다르게, Model 내부에서 다시 Service과 DAO로 나누어진다.
• Service는 오직 비즈니스 로직만 처리하고 그 결과를 반환하는 메서드들의 집합이다. Service에서 직접 DB의 데이터를 찾거나, 갱신, 삭제를 수행하지 않는다.
• DB와 통신하여 여러 연산을 수행하는 주체는 DAO로, DB에서 데이터 관련 연산을 수행할 때는 반드시 DAO만을 사용하여 접근할 수 있다.
• 이때 서비스가 DAO를 통해 DB의 데이터를 얻거나, 주기 위해서는 DB에 넣거나 찾아야 할 어떤 데이터를 넣어주어야 한다. 이때 이 데이터를 러프하게 주기 보다는 어떤 객체에 캡슐화하여 주는 것이 보안상 이유나 다루는 데 좀 더 편리하다.
  • 이러한 개념으로 나온 것이 DTO(Data Transfer Object)로 DAO에 넣거나 받을 데이터를 DTO로 통일함으로서 일관성 있게 데이터를 다룰 수 있다.
  • 다만 DB에서 DAO로 이동하는 것은 조금 다른데. 이는 DAO에서 어떠한 이유로든 DB에서 받은 데이터가 변질되어 Service로 넘어가선 안되기 때문이다. 이를 위해 만든 객체가 VO(Value Object)이다.
  • 따라서 VO는 DTO와는 달리 "값의 변경"이 불가능하도록 세팅되어 있는 Read Only의 특성을 가진다. 보통VO는 DAO - DB간 통신에서 사용되고, 그 이외에 파트에서 서로 데이터가 오고 가는데는 DTO가 사용된다.

 

 

Spring에서의 MVC패턴 개발

• Spring 역시 Spring MVC를 통하여 이러한 MVC 패턴 디자인을 지원하고 있다. 일반적으로 구조는 아래와 같다.

• request가 들어오면 톰켓 서버를 거쳐 스프링 컨테이너(자세하게는 Distpatcher Servlet이라는 모든 요청을 받는 부분이 있지만 지금은 넘어간다,)로 들어간다.
• 이때 스프링 컨테이너는 해당 요청에 대응하는 Controller가 존재하는지를 확인하는데 이는 서블릿 시절과 꽤 유사하게 url mapping을 통해 수행한다. 차이점은 오직 @Controller 또는 @Component로 어노테이션이 적힌 부분만 찾는다는 것인데. 이는 Spring에서 자신에게 등록된 컨트롤러나 컴포넌트만 찾아서 확인하는 특징이다.
• 이후 어떠한 처리(Service, DAO등등을 통해) 이후 가공된 데이터를 받은 Controller는 ViewResolver에게 보여주어야 할 웹 페이지 이름을 String으로 반환한다. viewResolver는 템플릿 엔진을 통해 받은 데이터들을 표현하도록 렌더링 하고, 완성된 html 문서를 클라이언트에게 response로 반환한다.