Servlet 방식 <= Spring MVC 방식 비교

[ Servlet 방식 <= Spring MVC 방식 ] 비교


- Servlet 은 MVC 방식의

1. Controller 역할 ( Mapping )
2. Service단 역할 ( 로직 구현 )
3. View단 역할 ( HttpServletResponse )

4. Repository = DAO
5. DTO = HttpServletRequest

- 크게보면 이렇게 대칭되는 듯 하다.


MVC 에선
- DTO 로 자동으로 받아오던 사용자 입력값(name/value)을
HttpServletRequest 로 직접 받아온다.
( 객체에 넣어서 통째로 편하게 사용하기 위해서
직접 받아온 뒤, DTO 를 만들어 dto 객체화 해서 사용 )

MVC 에선
- DB 와 접촉해 데이터를 주고 받던 Repository 역할을
JDBC 방식으로 직접 쿼리문을 작성해 DB와 접촉한다.
이걸 하는 클래스를 DAO 라 부른다.

MVC 에선
- Controller 에서 주로
1. Mapping해주고
2. Service 단과 View 단 사이를 중간에서 연결해주던 역할을 했는데


Servlet 도 Mapping 은 똑같이 한다.

근데 MVC에서는 요청에 대해 응답할 때,
응답값을 Model 에 담아서 View 단에 주기만 했지
실질적으로 View 단에 손을 대진 않았다.

근데 Servlet은 모델이 없던 시절이기 때문에
직접 View 단에 손을 대고, 직접 View단을 태그를 써가며 만들어낸다.

이게 가장 큰 차이점인 것 같다.

MVC 가 편한 것도 편한거지만
응답값을 "Model" 에 담아서 뷰단에 넘기기만 하면 되니

"응답" 값을 표현하는 페이지를 구현하는데 있어서
직접 예쁘게 만든 View 단 페이지에 응답값만 넘겨서 만든 페이지와

직접 Servlet 이 PrintWriter 등을 사용해서 힘겹게 만드는 페이지랑은
차이가 날 수 밖에 없을 것 같다.


Servlet 을 보니
왜 최근들어서야 FrontEnd 와 BackEnd가 나뉘어졌는지가 더 와닿는다.

혼자서 로직짜고 뷰단짜고 맵핑하고 이것저것 다하던 Servlet 이
바로 지난시절 혼자 모든 단의 개발을 도맡아 하던 개발자분들의 모습이 아닐까.

이젠 Model 이란 개념이 생겨났고,
서버는 응답을 이 Model 에 담아서 넘기기만 하면 되니
View 단과 서버단은 확실히 자기 역할이 생겨났다.

BackEnd는 DB 를 관리하고, 이를 통해 Service 단에서 로직을 구현하고,
Mapping 해주는 역할에 집중하게 되었고,
( DB의 효율적 관리가 서버유지비용과 직결되고,
로직의 효율성이 서버 속도, 요청을 처리할 수 있는 양을 정하기 때문에
이 또한 DB 와 직결 되어있다. 효율과의 싸움을 통해 비용을 절감해낸다 )

FrontEnd는 Model로 받아온 응답값을 화면에 "이쁘게" 구현하고, 클라이언트 단에서 할 수 있는 로직처리에  집중하게 되었다.
( 저 이쁘게가 그냥 정적인 이쁘게에서 끝났으면 사실 그렇게 어려울 것도 없겠으나,
조건에 따라 이벤트를 걸고, 동적인 화면을 구성하기 위해서는
JavaScript안에서
"사용자의 입력값" 과 "서버에서 받아온 Model에 담긴 응답 값"
을 가지고 한땀한땀 로직을 짜야하기에 그 깊이와 전문성이 깊어져 가고 있는 것 같다. )