1.5.4. Ajax 모델과 MVC 패턴
MVC는 Model-View-Control의 약자이다. 사용자에게 프레젠테이션을 제공하는 View, 비즈니스 로직을 처리하는 Model, View와 Model을 제어하는 Control로 분리하여 애플리케이션을 개발하는 형태를 의미한다.
MVC 패턴은 모든 기능을 하나의 애플리케이션에 작성함에 따라 소스가 복잡하게 되어 개발과 유지보수가 어렵게 되는 것을 피하기 위함이며 객체지향 방법, 컴포넌트 방법을 실현할 수 있다는 것이 MVC 패턴의 장점이다.
상기 그림은 JSP/Java 환경에서의 MVC 패턴 계층 구조도이다. 프로젝트 환경에 따라 EJB 컨테이너를 사용하지 않을 수 있으며, 데이터베이스와 애플리케이션 서버가 하나로 통합될 수 있다. 하지만, 서블릿과 JSP/HTML은 분리하는 것이 일반적이다. 왜냐하면 JSP에 서블릿 기능과 HTML을 포함하면 JSP가 너무 복잡해지기 때문이다.
n 회원정보 조회: 전통적인 웹 애플리케이션의 MVC 패턴 흐름
|
MVC |
실행 주체 |
처리 프로세스 |
|
View |
JSP |
사용자가 브라우저에서 아이디와 패스워드를 입력하고 확인 버튼을 클릭한다. |
|
Control |
서블릿 |
브라우저 요청을 받아 요청 사항을 분석한다. |
|
서블릿 |
EJB를 호출한다. | |
|
Module |
EJB |
데이터베이스에서 회원정보를 추출한다. |
|
EJB |
필요한 경우 다른 서버의 애플리케이션을 호출한다. | |
|
EJB |
JSP에 회원정보 데이터를 넘겨준다. | |
|
View |
JSP |
HTML을 해석한다. |
|
JSP |
회원정보 데이터를 표시한다. |
상기의 흐름은 회원정보 조회를 하는 전통적인 웹 애플리케이션의 MVC 패턴 흐름이다. 서블릿에서 EJB를 호출하지 않고 직접 회원정보 데이터를 추출하여 JSP에 넘겨주는 것과 같이 다른 형태로 처리할 수 있지만, 상기 흐름에서 많이 벗어나지는 않는다.
그런데, 브라우저에서 데이터를 입력하는데 실행 주체가 JSP이다. 이는 확장자 *.HTML이 별도로 있는 것이 아니라 JSP에 포함되어 있기 때문이다. 그림에는 클라이언트에 브라우저가 그려져 있지만, 사실 브라우저가 모양만 갖춘 것이지 이를 실행하는 주체는 서버에 있는 JSP이다. 진정한 MVC 패턴이라고 하기에는 조금 어색한 면이 있다.
[그림 1-5] Ajax MVC 패턴 계층 구조도
상기 그림은 Java 환경에서의 Ajax MVC 패턴 계층 구조도이다. EJB 컨테이너, 데이터베이스, 애플리케이션 서버는 바뀐 것이 없다. 즉, 모듈을 담당하는 부분은 전통적인 웹 애플리케이션과 Ajax 웹 애플리케이션 구조가 동일하다.
클라이언트 부분은 변경된 것이 있다. Ajax 엔진이 클라이언트에 위치하여 브라우저에서 입력한 데이터를 접수하여 서블릿에 보낸다. 또한, Ajax 엔진이 서블릿에서 결과를 받아 브라우저에 출력한다. 즉, 클라이언트에서 View와 Control을 수행하고 있다.
웹 컨테이너의 서블릿은 존재하나 Control 대상이 JSP에서 Ajax 엔진으로 변경되었으며, 처리 결과를 JSP에 넘겨주던 것을 Ajax 엔진에 넘겨준다. 여기서 많은 변화가 있는 것이 JSP/HTML이다. 상기 그림에서 보는 것과 같이 JSP/HTML이 중앙에 있는 웹 서버 그림에 없다. 즉, 클라이언트가 View를 담당하게 되므로 View를 담당하던 JSP가 필요 없게 되었다
HTML을 해석하는 것은 브라우저 본연의 기능이므로 브라우저에 넘겼으며, 브라우저에 출력하기 위해 수행했던 사항을 Ajax 엔진이 수행하게 되므로 JSP는 할 것이 없다. JSP/ASP가 할 것이 없다는 것은 또 다른 소프트웨어 세계를 예고한다. Ajax의 등장으로 인해 프레젠테이션을 담당하는 서버용 스크립트 언어의 필요성에 대해 다시 한번 생각하는 계기가 되었다.
n 회원정보 조회: Ajax 웹 애플리케이션의 MVC 패턴 흐름
|
MVC |
실행 주체 |
처리 프로세스 |
|
View |
브라우저 |
사용자가 브라우저에서 아이디와 패스워드를 입력하고 확인 버튼을 클릭한다. |
|
Control |
Ajax 엔진 |
버튼이 클릭된 것을 인식하여 서버의 서블릿 애플리케이션을 호출하고 아이디와 패스워드를 서버로 보낸다 |
|
Control |
서블릿 |
Ajax 엔진 요청을 받는다. |
|
서블릿 |
EJB를 호출한다. | |
|
Module |
EJB |
데이터베이스에서 회원정보를 추출한다. |
|
EJB |
필요한 경우 다른 서버의 애플리케이션을 호출한다. | |
|
EJB |
서블릿에 회원정보 데이터를 넘겨준다. | |
|
Control |
서블릿 |
EJB에서 데이터를 받아 Ajax 엔진으로 보낸다 |
|
Control |
Ajax 엔진 |
서버로부터 데이터를 받아 HTML 태그에 데이터를 편집한다 |
|
View |
브라우저 |
HTML 태그를 해석하여 회원정보를 출력한다 |
상기의 흐름은 회원정보를 조회하는 Ajax 웹 애플리케이션의 MVC 패턴 흐름이다. 이에 대한 설명은 읽어 보면 이해할 수 있으므로 설명을 생략한다.
상기 그림과 흐름에서 볼 수 있듯이 틀림없이 변화가 예상된다. 사실, JSP/ASP를 사용하지 않고 Ajax를 도입한다는 것은 망설여지는 사항이기도 하다. 기존에 개발된 것이 너무 많기 때문이다. 그렇다고 사용자의 요구를 언제까지 외면할 수는 없다.
이런 가운데 두 마리 토끼를 잡기 위해 JSP/ASP에 Ajax를 적용하려는 움직임이 있지만, 껍데기와 알맹이가 본질적으로 기능이 다른 것을 맞춘다는 것은 바람직한 모습이 아니다. 이것이 현 시점에서 우리 개발자에게 판단을 요구하는 사항이기도 하다.
표준 측면에서 볼 때 ASP/JSP는 특정 업체에서 개발한 소프트웨어다. 하지만, Ajax 기술은 W3C 표준에 준거한다. 물론, W3C 표준도 업체/단체에서 제정하지만, 임의로 결정할 수 없으며 다수의 의견과 견제가 반영되어 제정된다. 특정 업체 기준으로 웹 애플리케이션을 개발하는 것은 바람직한 방향이 아니며, 종속적인 기술로 인해 그 동안 많은 시간과 노력을 허비한 경험을 가지고 있다.