기반기술재공부 - MVC 패턴
예를들어 MFC가 그렇다.
1.1.1 Classic MVC becomes outdated
- MVC 3개의 레이어로 구성되어 레이어별 역할이 뚜렷하기 때문에 협업이 용이하고, 디자인과 코딩의 분리가 자연스럽다.
- JSP 페이지에 비즈니스 로직이 제외되므로 가독성이 증가하고 유지보수가 용이하다.
- M(Model) : BO (Business Object), DO(Domain Object), VO (Value Object) ...
- V(View) : HTML(정적인 컨텐츠) , JSP(동적인 컨텐츠)..
- C(Controller) : (ex) Servlet
첫번째는 MVC의 가장 기본적인 패턴이다
View는 Model로부터 전달된 model-change 이벤트를 받아 데이터를 갱신한다.
예를 들어 회원이 로그인을 한다를 세 파트로 나눠서 보면,
View : 웹페이지에 떠있는 ID와 Password입력용 텍스트박스와 Log-in 버튼 정도가 되겠습니다.
Model : ID와 Password를 입력하면 이 값을 자바에서 사용가능한 자료형으로 변환을 해서 보관을 합니다.
이 역활을 담당해주는게 Model입니다.
Control : 실질적인 역활 수행을 하게 됩니다.
입력된 값을 받아서 DB의 내용을 조회해보게 되겠죠.
자 다시 얘기하자면, 웹페이지에 텍스트 박스와 로그인버튼이 있는 화면을 제공하는 부분과 Log-in버튼을 눌렀을때 웹페이지의 텍스트박스안에 입력한 값을 넘겨 받는 부분 그리고 이 값을 가지고 로그인 과정을 수행한뒤 결과를 반환하는 과정. 이렇게 3부분으로 나눈게 바로 MVC패턴이 되겠습니다.
하지만 오랜 경험상 다들 아시겠지만, 변하지 않는 패턴은 죽은 패턴입니다.
이 MVC패턴도 변화하게 되는데, 다음은 그 2번째 모형입니다.
새로 추가된게 보이시나요?
Dispatcher가 추가된게 새 MVC 패턴입니다.
1.1.2 Classic MVC gets an update: the Front Controller
기본적인 MVC패턴은 하나의 로직은 하나의 모델과 하나의 컨트롤을 가졌습니다.
MVC 패턴의 목적은 M-V-C를 나눔으로서 웹디자이너와 프로그래머 사이의 분업을 보다 쉽게 하기 위함이었습니다.
마찬가지로 어플리케이션 개발에서도 MVC패턴을 사용합니다. GUI 따로 프로그래밍 따로죠.
여기서 문제점이 발생하게 되는데, 기본MVC모델은 프로그래머가 뭔가 바꿧을 경우...
예를 들자면, 메소드의 이름을 하나 바꿨을 경우라던가 파일명을 바꿨다라던가 했을 때
Control을 직접 view에서 호출하기 때문에 디자이너와의 썸씽이 불가피하게 됩니다.
그래서 Dispatcher가 추가된 새 모델이 나오게 됩니다.
이 Dispatcher는 말 그대로 분류해주는 역활을 하게 됩니다. WINAPI를 해보셨다면 이해가 쉬우실겁니다.
비교해서 말하자면 기존에는 view에서 bean을 부르고 id와 password에 매치시켜준뒤 해당 메소드를 호출함으로서 결과를 얻게 되고 이 결과에 따라 웹페이지를 사용자에게 보여주면서 하나의 로직이 끝나게 됩니다.
새 모델에서는 view에서는 일체의 bean과 연동되는 작업이 없습니다. 단지 이 Dispatcher에게 post든 get이든 값을 넘겨줄때 파라미터를 하나 더 추가해줍니다.
"LOGIN"이라는 파라미터지요.
네 이제 감이 잡히시나요? Dispatcher에선 이 파라미터를 분석해서 어떤 서비스를 호출할 것인가를 결정하는 겁니다.
다시 짧게 정리하자면
기존 모델 : view에서 직접 로직을 호출. (예) LOGIN에 관련된 메소드를 호출한다.
새 모델 : view에서 약속된 파라미터를 추가한 값을 Dispatcher에게 넘겨주면 이 Dispatcher에서 로직을 호출.
(예) view에서 "LOGIN"이라는 파라미터가 추가된 값을 post or get으로 넘겨준다. Dispatcher에서
LOGIN이라는 값을 가지고 LOGIN에 관련된 메소드를 호출한다.
이리하여 진정한! MVC패턴이 나타나기 시작합니다.
프로그래머는 웹마스터에게 단지 로긴할땐 Login이란 값을 파라미터로 넘겨라 라고 주문만 하고 로긴에 관련된 메소드는
boolean 웹마스터귀는당나귀귀(String id, String pass){...} 라고 만들어도 아무런 문제가 없게 된겁니다.
다음은 마지막 MVC패턴 차례가 되겠습니다.
1.1.3 MVC evolves: the Page Controller
- 수행 될 controller를 dispatcher를 이용하여 찾지 않고 view를 직접 호출하면, view가 렌더링되기 전에 controller를 직접 호출한다.
- Page Controller는 X,Y,Z 작업을 분리하여 좀 더 모듈화가 된 것으로 보인다.
- WebWork에서는<webwork:action> 커스텀 태그를 이용해 Page Controller를 지원한다.
- Struts에 익숙하다면 Front Controller 패턴이 매우 익숙하지만, 몇 몇 프레임워크는 캡슐화가 용이하기 때문에 Page Controller를 수용한다.
예, 이번엔 Dispatcher가 사라졌군요? 그리고 조금 복잡해 보입니다.
하지만 모든 일이 그렇듯 알고 보면 별게 아니...ㄹ겁니다.
사실 Dispatcher가 사라진거 같이 보이지만, 그건 눈속임 입니다.
View.jsp를 감싸고 있는 Page Controller라는게 추가가 됩니다.
이녀석은 로그인과 로그아웃이라는 작업 형태를 Action으로 분리해서 가지고 있습니다.
사용자가 로그인을 선택하면 로그인Action을 로그아웃을 선택하면 로그아웃Action을 호출합니다.
어떤가요? 하는 일이 Dispatcher와 똑같죠.
네...그럼 차이점을 한번 살펴보겠습니다.
Front controller 1.1.2 방식에서는 파라미터를 가지고 요청의 성질을 결정했습니다.
이런 접근 방식은 웹디자이너와 프로그래머의 일을 확실히 나누기 위함 입니다.
Page Controller에서는 커스텀 테그를 이용하여 이 과정을 거치게 됩니다.
즉, 태그를 사용함으로서 직관적으로 서비스와의 연동을 이룰 수 있으며 약속된 태그를 사용함으로서 분업을 이룰 수 있게 해줍니다.
이 패턴은 한번도 적용해 본 적이 없어서 확실히 말씀드리기 어렵습니다만... 추측하기에 Struts의 그것과 비슷하지 않을까 싶습니다.
MVC패턴은 웹에서는 굉장히 요긴한 패턴입니다. ㅇ_ㅇ/