Web Presentation Patterns
웹 프레젠테이션의 핵심은 Model View Controller(MVC)와 그 변형들이다.
Model View Controller
MVC는 아마 소프트웨어에서 가장 많이 언급되면서도 가장 많이 오해받는 패턴이다. Fowler는 웹 맥락에서 "controller"가 혼동을 일으키므로 input controller라는 용어를 선호한다.
웹 서버에서의 MVC 흐름
핵심 원칙: Model은 View와 Controller의 존재를 절대 모른다. 이 분리 덕분에 같은 도메인 위에 웹 UI, CLI, API를 별도로 붙일 수 있다.
Input Controller 패턴
Page Controller
URL(또는 페이지)마다 하나의 controller. 가장 단순하다. 문서 중심 사이트에 적합하다. 대부분의 웹 프레임워크가 기본적으로 이 방식을 제공한다.
Front Controller
모든 요청이 하나의 controller를 통과한 뒤, 요청 유형에 따라 적절한 핸들러로 분기한다. 복잡한 네비게이션, 인증·인가·로깅 같은 공통 처리가 많을 때 유리하다. Java의 Struts가 대표적.
View 패턴
Template View
서버 페이지(JSP, ASP, Razor, Jinja) 방식. HTML 안에 동적 코드 삽입. 가장 흔하고 직관적이지만, 로직이 View에 침투하기 쉬운 위험이 있다.
Transform View
모델 데이터를 XSLT 같은 변환 엔진으로 HTML로 변환. Template View보다 테스트하기 쉽다(입력=XML, 출력=HTML이라 자동화 가능). 하지만 XSLT 자체의 학습 곡선이 있다.
Two Step View
모델 → 논리적 화면(중간 표현) → 최종 HTML. 같은 데이터를 다양한 룩앤필로 보여줘야 할 때(예: 다국어 사이트, 멀티 브랜드) 유용하다.
Application Controller
Input Controller와는 다른 개념이다. 화면 흐름과 네비게이션을 관리하는 중재자. Presentation과 Domain 사이에 위치하며, "이 입력을 받으면 다음에 어떤 화면을 보여줄지"를 결정한다.
모든 시스템에 필요한 것은 아니다. 화면 흐름이 복잡하거나, 여러 UI가 같은 플로우를 공유할 때 유용하다.
웹 서버 프로그램의 두 가지 형태
Script 방식: CGI, Servlet 같은 프로그래밍 코드. 요청 해석에 강하다.
Server Page 방식: PHP, JSP, ASP 같은 HTML 안에 코드 삽입. 응답 포맷팅에 강하다.
최선의 조합: 요청 해석은 Script(Controller), 응답 포맷팅은 Server Page(View). 이것이 바로 MVC의 C와 V를 물리적으로 분리한 것이다.
우리 프로젝트에의 적용
Drogon(C++ 웹 프레임워크)은 기본적으로 MVC를 지원한다:
- Controller: Drogon의 HttpController 또는 HttpSimpleController가 Input Controller 역할
- View: CSP(C++ Server Pages) 템플릿이 Template View
- Model: 우리가 Larman으로 설계한 도메인 클래스들
Page Controller 스타일로 시작하되, API 엔드포인트가 많아지면 Front Controller로 전환을 고려하면 된다.