[Compound Pattern] MVC(Model-View-Controller): MVC와 웹 환경
모델 2(Model 2)
웹이 퍼진지 얼마 되지 않아서 여러 개발자들이 MVC를 브라우저/서버 모델에 맞게 변형시켜 사용하였다. 그 중 "모델 2"가 있다.
source: https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=gream50&logNo=221335090609
서블릿과 JSP 기술을 사용하며 일반적인 GUI를 사용하는 경우와 마찬가지로 모델, 뷰, 컨트롤러를 분리해서 디자인할 수 있다.
-
사용자가 HTTP 요청을 하면 서블릿에서 그 요청을 수신한다.
사용자가 웹 브라우저를 통해 HTTP 요청을 한다. 이때 보통 사용자 ID와 비밀번호와 같은 '폼 데이터'가 함께 전달된다. 서블릿에서는 이런 폼 데이터를 받아서 파싱한다. -
서블릿은 컨트롤러 역할을 한다.
서블릿은 컨트롤러 역할을 맡아서 사용자 요청을 처리하고, 대부분의 경우 모델(보통 DB)에 어떤 요청을 하게 된다. 요청을 처리한 결과는 자바빈 형태로 포장된다. -
컨트롤러에서는 컨트롤을 뷰한테 넘긴다.
뷰는 JSP에 의해 표현된다. JSP에서는 (자바빈을 통해서 얻은) 모델의 뷰를 나타내는 페이지만 만들어주면 된다. 물론 페이지를 만든느 과정에서 다음 단계의 작업을 위해 몇 가지 제어해야 할 일이 추가될 수 있다. -
뷰에서 HTTP를 통해 브라우저에 페이지를 전달한다.
페이지가 브라우저한테 전달되며, 그 웹 페이지가 사용자의 화면에 표시된다. 사용자가 또 다른 요청을 할 수도 있으며, 새로운 요청도 지금까지 설명한 것과 같은 방식으로 처리된다.
모델 2의 장점
모델 2는 단지 MVC가 적용된 깔끔한 디자인에 불과한 것이 아니다. 단순히 디자인적인 면에서 각 구성요소를 분리해주는 것에 그치지 않는다는 의미이다. 제작 책임까지도 분리시킬 수 있다.
개발자들은 서블릿에만 전념하면 되소, 웹 제작자들은 간단한 모델 2 스타일의 JSP만 다루면 되는 환경이 조성되었다. 그래서 웹 제작자들은 HTML과 간단한 자바빈만 만지면 되는 것이다. (예를 들어 폼 데이터 파싱과 같은 작업에 자유로워 질 수 있다.)
MVC가 적용된 웹 프로그래밍
source: https://m.blog.naver.com/pjok1122/221728877690
모델 2에서의 옵저버, 전략, 컴포지트 패턴
옵저버 패턴
모델 2에서의 고전적인 MVC 의미에서 본다면 뷰는 더 이상 모델의 옵저버라 할 수 없다. 모델한테 등록해서 모델의 상태가 바뀌었다는 연락을 받지 않는다는 뜻이다.
하지만 여전히 모델의 상태가 바뀔 때 컨트롤러를 통해 간접적으로나마 연락을 받긴 합니다. 게다가 컨트롤러에서는 뷰한테 빈을 건네주기 때문에 뷰에서 모델의 상태를 알아낼 수 있다.
브라우저 모델을 생각해 보면, 뷰에서는 브라우저로 HTTP 응답을 할 때만 모델의 상태에 대한 정보가 필요하다. HTTP 응답을 하지 않는 상황에서는 모델로부터 연락을 받아봤자 할 일이 없다. 페이지를 만들어서 브라우저로 보낼 때에만 모델의 상태를 반영하여 뷰를 생성하는 것이 의미있는 행동이 되는 것이다.
전략 패턴
고전적인 MVC에서처럼 뷰 객체에 컨트롤러 객체에 대한 참조가 들어가는 방식으로 구현되어 있진 않다. 그럼에도 컨트롤러 서블릿이 뷰의 행동을 구현하는 객체라는 점, 그리고 다른 행동을 원하는 경우에 다른 컨트롤러로 바꿀 수 있다는 점에서 보면 여전히 전략 패턴을 따른다고 할 수 있다.
컴포지트 패턴
Swing GUI와 마찬가지로 여기에 쓰이는 뷰도 결국은 중첩된 그래픽 구성요소로 이루어진다. 이 경우에는 HTMP 코드를 통해서 웹 브라우저에 렌더링된다는 차이점이 있긴 하지만, 그 밑에는 결국 복합 객체 형태의 객체 시스템이 있을 가능성이 매우 높다.
모델
MVC에서 모델은 뷰나 컨트롤러에 대해서 알 필요가 없다. 바꿔 말하자면 뷰나 컨트롤러로부터 완전히 분리되어 있다. 그저 연락을 돌려줘야 할 옵저버가 있을 수 있다는 사실만 알고 있으면 된다(옵저버 패턴을 썻기에 이러한 장점을 누릴 수 있음). 모델에서는 그 외에도 뷰와 컨트롤러에서 모델의 상태를 알아내거나 설정하기 위해 쓸 수 있는 인터페이스를 제공한다.
모델 자체는 다른 클래스에 의존하지 않기에 기존(이전 포스팅)에 구현하였던 BeatModel 클래스를 그대로 사용하면 된다.
컨트롤러(서블릿)
서블릿이 컨트롤러의 역할을 한다. 웹 브라우저로부터 HTTP 요청을 받아 모델에 적용할 수 있는 행동으로 해석해주는 기능을 제공하면 된다.
뷰(JSP)
모델 2에서 뷰는 그냥 JSP이다. JSP에서 알 수 있는 것은 컨트롤러로부터 받은 빈 뿐이다. 지금 상황에서는 모델 자체가 빈으로 전달되고, JSP에서는 그 중 BPM 속성을 가지고 현재 분당 비트수를 알아낸다. 그 데이터를 가지고 사용자에게 분당 비트수 정보를 보여주고, 그 외에 비트 생성기 제어용 사용자 인터페이스도 만들어서 제공한다.
