웹 프레젠테이션 패턴

Model View Controller (MVC)

**Model View Controller (MVC)**는 사용자의 인터페이스 상호작용을 세 가지 별도의 역할로 분리하는 아키텍처 패턴입니다. 이 패턴은 1970년대 후반에 Smalltalk 플랫폼을 위해 Trygve Reenskaug에 의해 개발되었으며, 이후 대부분의 UI 프레임워크에 큰 영향을 미쳤습니다. MVC는 세 가지 주요 컴포넌트로 구성됩니다.

  • 모델 (Model): 모델은 도메인 정보에 대한 객체로, 비주얼적인 요소를 포함하지 않는 데이터를 보유하며, 비즈니스 로직과 데이터 처리 기능을 담당합니다. 순수한 객체 지향 프로그래밍에서는 모델이 도메인 모델의 객체가 됩니다. 모델은 UI의 구조와는 독립적으로 존재하며, UI에 대한 의존성이 없습니다. 이는 모델이 다른 프레젠테이션 계층에 독립적으로 동작할 수 있게 하며, 다양한 인터페이스에 동일한 모델을 사용할 수 있는 장점을 제공합니다. 또한, 모델은 비시각적 객체이기 때문에 테스트가 용이합니다.

  • 뷰 (View): 뷰는 사용자에게 데이터를 보여주는 UI의 일부로, 모델의 데이터를 기반으로 화면에 정보를 렌더링합니다. 뷰는 모델에서 데이터를 가져와 사용자가 이해할 수 있는 형태로 표시하는 역할을 하며, 사용자가 상호작용할 수 있는 인터페이스를 제공합니다. 모델에서 변경된 데이터는 뷰에서 즉시 반영될 수 있습니다. 뷰는 화면에 데이터를 표시하는 역할만 수행하고, 데이터 변경은 컨트롤러를 통해 처리됩니다.

  • 컨트롤러 (Controller): 컨트롤러는 사용자 입력을 처리하고, 모델을 조작하며, 그 결과를 뷰에 반영하는 역할을 담당합니다. 컨트롤러는 사용자의 입력을 받아들이고, 이 입력을 바탕으로 모델의 상태를 변경하며, 그 변경 결과를 뷰에 전달하여 화면을 업데이트합니다. UI에서 사용자의 액션에 따라 모델과 뷰가 어떻게 반응해야 하는지를 결정하는 핵심적인 컴포넌트입니다.

MVC의 핵심 이점은 프레젠테이션(뷰)과 비즈니스 로직(모델)을 분리함으로써 코드의 유지보수성과 확장성을 높인다는 점입니다. 예를 들어, 동일한 모델에 대해 여러 종류의 뷰를 제공하거나, 모델을 변경하지 않고도 프레젠테이션을 독립적으로 변경할 수 있습니다. 또한, 모델이 뷰에 의존하지 않기 때문에, 도메인 로직을 쉽게 테스트할 수 있으며, 새로운 프레젠테이션을 추가할 때에도 모델을 변경할 필요가 없습니다.

하지만, MVC의 구현에서 뷰와 컨트롤러의 분리는 덜 중요하게 여겨질 수 있습니다. 일부 GUI 프레임워크는 뷰와 컨트롤러를 결합하여 제공하는 경우가 많습니다. 이는 뷰와 컨트롤러의 분리가 불필요하거나 복잡한 코드 구조를 만들 수 있기 때문입니다. 웹 인터페이스에서는 컨트롤러와 뷰의 분리가 유용할 수 있지만, 리치 클라이언트 시스템에서는 그렇지 않을 수 있습니다.

Page Controller

Page Controller는 웹사이트의 특정 페이지나 동작을 처리하는 객체입니다. 웹 애플리케이션에서 각 페이지 요청을 처리하는 방식은 정적 HTML 페이지에서 시작되었습니다. 정적 페이지에서는 사용자가 요청하는 URL이 실제로 서버에 존재하는 HTML 파일을 가리킵니다. 하지만, 동적 페이지에서는 URL이 파일과 1:1로 매핑되지 않고, 논리적인 페이지나 액션을 처리하는 Page Controller에 의해 처리됩니다.

Page Controller의 동작 방식:

  • URL 디코딩: Page Controller는 사용자가 요청한 URL을 디코딩하고, 요청에서 데이터를 추출하여 액션을 결정합니다. 이를 통해 어떤 페이지를 표시해야 하는지, 또는 어떤 동작을 수행해야 하는지를 판단합니다.

  • 모델 생성 및 실행: Page Controller는 요청된 데이터를 기반으로 모델 객체를 생성하거나 호출하여 필요한 비즈니스 로직을 수행합니다. 이 과정에서 데이터베이스와의 상호작용이 포함될 수 있습니다.

  • 뷰 선택 및 전달: Page Controller는 처리 결과를 기반으로 어떤 뷰를 사용자에게 보여줄지를 결정하고, 해당 뷰를 렌더링하여 사용자에게 반환합니다.

Page Controller의 활용 사례: Page Controller는 웹 애플리케이션에서 각 페이지가 비교적 단순한 논리를 가지는 경우 유용합니다. 예를 들어, 대부분의 페이지가 단순히 데이터를 표시하는 역할을 한다면, Page Controller를 사용하여 해당 요청을 처리하고, 결과를 반환하는 것이 적절합니다. 이 방식은 개발자가 URL과 페이지 간의 관계를 명확하게 이해할 수 있게 해주며, 유지보수가 쉽습니다.

하지만, Page Controller는 네비게이션이 복잡한 웹사이트에서는 비효율적일 수 있습니다. 이 경우 Front Controller를 사용하여 모든 요청을 중앙에서 처리하고, 필요한 로직을 분리하여 관리하는 것이 더 효과적일 수 있습니다.

Front Controller

Front Controller는 웹사이트의 모든 요청을 중앙에서 처리하는 패턴입니다. 복잡한 웹 애플리케이션에서는 사용자 요청을 처리하는 공통적인 작업이 많이 필요합니다. 예를 들어, 인증, 로깅, 국제화, 특정 사용자에게 특정 뷰를 제공하는 것 등이 있습니다. 이러한 작업이 여러 Page Controller에 분산되어 있을 경우, 코드 중복이 발생하고 유지보수가 어려워질 수 있습니다. Front Controller는 이러한 문제를 해결하기 위해 모든 요청을 중앙에서 처리하고, 공통 작업을 한 곳에서 관리할 수 있도록 합니다.

Front Controller의 동작 방식:

  • 웹 핸들러: Front Controller는 웹 서버에서 모든 요청을 받아들이는 역할을 합니다. 웹 핸들러는 URL에서 정보를 추출하고, 어떤 동작을 수행할지 결정한 후, 해당 동작을 처리하는 명령 객체에 위임합니다.

  • 명령 객체: 각 요청에 대해 수행할 구체적인 동작은 명령 객체에 의해 처리됩니다. 명령 객체는 도메인 로직을 실행하고, 그 결과를 생성합니다.

  • 뷰 결정: 요청이 처리된 후, Front Controller는 어떤 뷰를 사용자에게 보여줄지를 결정하고, 해당 뷰를 렌더링합니다.

Front Controller의 장점:

  • 중앙화된 요청 처리: 모든 요청을 한 곳에서 처리하기 때문에, 웹 서버의 설정이 단순해지고, 유지보수가 쉬워집니다. 새로운 명령을 추가할 때도 다른 부분을 변경하지 않고 추가할 수 있습니다.

  • 코드 중복 감소: 여러 페이지에서 공통적으로 수행해야 하는 작업(예: 인증, 로깅)을 중앙에서 처리할 수 있어 코드 중복을 줄일 수 있습니다.

  • 동적 동작 변경: 실행 중에도 공통 동작을 변경하거나 추가할 수 있어, 유연한 시스템 구성이 가능합니다.

Front Controller의 사용 사례: Front Controller는 복잡한 네비게이션 구조를 가진 웹 애플리케이션에서 유용합니다. 예를 들어, 다양한 사용자 유형(일반 사용자, 관리자 등)에 따라 다른 화면을 보여줘야 하는 경우, Front Controller를 통해 중앙에서 요청을 처리하고, 사용자 유형에 맞는 명령 객체를 호출할 수 있습니다.

하지만, Front Controller는 구조가 복잡해질 수 있으므로, 모든 애플리케이션에 적합한 것은 아닙니다. 단순한 웹사이트에서는 Page Controller가 더 나은 선택이 될 수 있습니다.

Template View

Template View는 HTML 페이지에 마커(marker)를 삽입하여 동적 콘텐츠를 표시하는 패턴입니다. 이 패턴은 정적 HTML 페이지와 유사한 방식으로 동적 웹 페이지를 구성할 수 있게 해주며, HTML 마크업과 동적 데이터를 결합하는 데 유용합니다. Template View는 일반적으로 서버 페이지 (예: JSP, ASP, PHP)에서 구현되며, 이 패턴의 주요 목표는 HTML의 구조를 최대한 유지하면서 동적 콘텐츠를 삽입하는 것입니다.

Template View의 동작 방식:

  • HTML 템플릿 생성: 먼저, 정적 HTML 페이지와 유사하게 HTML 템플릿을 작성합니다. 이 템플릿에는 데이터를 삽입할 마커가 포함됩니다.

  • 마커 대체: 서버는 요청을 처리한 후, 템플릿에서 마커를 찾아 실제 데이터를 삽입합니다. 예를 들어, 데이터베이스에서 가져온 값이나 사용자가 입력한 데이터를 마커 위치에 삽입합니다.

  • 최종 페이지 생성: 마커가 데이터로 대체된 후, 최종 HTML 페이지가 생성되고, 클라이언트에게 반환됩니다.

Template View의 장점:

  • WYSIWYG 지원: Template View는 HTML 템플릿을 사용하기 때문에,

WYSIWYG(What You See Is What You Get) 편집기를 사용하여 쉽게 페이지를 디자인할 수 있습니다. 이는 비개발자도 HTML 구조를 쉽게 수정할 수 있게 해줍니다.

  • 유연한 레이아웃 관리: 동적 콘텐츠를 다양한 레이아웃에서 재사용할 수 있어, 페이지 디자인의 유연성을 제공합니다.

Template View의 단점:

  • 로직의 혼합: Template View는 HTML과 비즈니스 로직이 혼합될 위험이 있습니다. 스크립트 코드를 너무 많이 삽입하면, HTML 템플릿이 복잡해지고 유지보수가 어려워질 수 있습니다.

  • 테스트 어려움: 대부분의 Template View 구현은 웹 서버 내에서 동작하기 때문에, 독립적인 테스트가 어려울 수 있습니다. 이는 웹 서버가 실행 중일 때만 테스트할 수 있다는 단점으로 작용합니다.

Template View의 활용 사례: Template View는 단순한 동적 웹 페이지를 구현할 때 적합합니다. 예를 들어, 뉴스 기사 페이지나 제품 정보 페이지와 같이 주로 데이터를 표시하는 역할을 하는 페이지에서는 Template View를 사용하여 쉽게 구현할 수 있습니다. 이 경우, 비즈니스 로직은 도우미 객체(helper)에 담고, 템플릿에서는 데이터를 표시하는 역할만 수행하도록 분리하는 것이 좋습니다.

Transform View

Transform View는 도메인 데이터를 HTML로 변환하는 패턴입니다. 이 패턴은 주로 데이터가 XML 형식으로 제공될 때 유용하며, XML 데이터를 HTML로 변환하기 위해 **XSLT(Extensible Stylesheet Language Transformations)**와 같은 기술을 사용합니다. Transform View는 데이터를 구조화된 방식으로 처리하고, 이를 HTML로 변환하는 데 초점을 맞추고 있습니다.

Transform View의 동작 방식:

  • 도메인 데이터 준비: Transform View는 먼저 도메인에서 데이터를 가져와 XML 형식으로 변환합니다. 이 XML 데이터는 도메인 모델에 기반하며, 특정 비즈니스 로직을 반영할 수 있습니다.

  • XSLT 변환: 준비된 XML 데이터는 XSLT를 사용하여 HTML로 변환됩니다. XSLT는 XML의 특정 요소를 찾아 해당 요소를 HTML 요소로 변환합니다. 이 과정에서 스타일이나 레이아웃을 정의할 수 있습니다.

  • 최종 HTML 생성: 변환된 HTML은 클라이언트에게 반환되어 웹 페이지로 렌더링됩니다.

Transform View의 장점:

  • 복잡한 데이터 구조 처리: Transform View는 XML을 기반으로 하기 때문에, 복잡한 데이터 구조를 처리하는 데 적합합니다. XML의 계층적 구조를 활용하여 다양한 데이터를 쉽게 변환할 수 있습니다.

  • 테스트 용이성: Transform View는 독립적으로 테스트할 수 있습니다. XSLT는 웹 서버 없이도 테스트할 수 있으며, 데이터를 다양한 방식으로 변환해 볼 수 있습니다.

Transform View의 단점:

  • XML과 XSLT의 복잡성: Transform View는 XML과 XSLT를 사용하기 때문에, 이러한 기술에 대한 학습 곡선이 있을 수 있습니다. 특히, XSLT는 함수형 프로그래밍 스타일을 따르므로, 기존 절차적 프로그래밍에 익숙한 개발자에게는 익숙하지 않을 수 있습니다.

  • HTML 편집의 제약: Transform View는 XML을 HTML로 변환하는 방식이므로, WYSIWYG 편집기에서 직접 편집하기 어렵습니다. HTML의 구조를 세밀하게 제어하려면 XSLT를 수정해야 합니다.

Transform View의 활용 사례: Transform View는 XML 데이터를 다루는 웹 애플리케이션에서 유용합니다. 예를 들어, 데이터가 XML로 제공되고, 이를 다양한 형태의 HTML로 변환해야 하는 경우, Transform View를 사용하여 효율적으로 데이터를 변환할 수 있습니다. 또한, XML 기반의 API 응답을 웹 페이지로 표시할 때도 이 패턴이 적합합니다.

Two Step View

Two Step View는 데이터를 HTML로 변환하기 전에 논리적 화면 구조로 변환하는 두 단계의 변환을 수행하는 패턴입니다. 이 패턴은 복잡한 웹 애플리케이션에서 일관된 디자인과 스타일을 유지하면서 다양한 페이지를 쉽게 관리할 수 있도록 돕습니다. Two Step View는 특히 다중 화면 레이아웃이나 다중 출력 형식을 지원해야 하는 경우에 유용합니다.

Two Step View의 동작 방식:

  • 1단계: 논리적 화면 구조 생성: 첫 번째 단계에서는 모델 데이터를 논리적인 화면 구조로 변환합니다. 이 논리적 구조는 HTML 태그가 아닌, 필드, 테이블, 헤더와 같은 화면 요소들로 구성됩니다. 이 단계에서는 화면 요소들 간의 관계와 데이터를 정의하지만, 구체적인 HTML 형식은 정의하지 않습니다.

  • 2단계: HTML로 변환: 두 번째 단계에서는 논리적 화면 구조를 실제 HTML로 변환합니다. 이 단계에서 화면 요소들은 HTML 태그로 변환되고, 스타일과 레이아웃이 적용됩니다.

Two Step View의 장점:

  • 글로벌 스타일 변경 용이성: 모든 페이지가 공통의 논리적 화면 구조를 공유하므로, 스타일이나 레이아웃을 전역적으로 변경하기가 쉽습니다. 예를 들어, 전체 사이트의 테이블 스타일을 변경하려면, 2단계 변환만 수정하면 됩니다.

  • 다중 출력 형식 지원: 동일한 논리적 화면 구조를 사용하여 다양한 출력 형식을 지원할 수 있습니다. 예를 들어, 웹 페이지뿐만 아니라 모바일 디바이스나 프린터에 최적화된 출력 형식을 생성할 수 있습니다.

Two Step View의 단점:

  • 구현 복잡성: Two Step View는 두 단계로 나누어진 변환 과정을 필요로 하므로, 구현이 복잡해질 수 있습니다. 또한, 논리적 화면 구조를 설계하는 데 시간이 더 소요될 수 있습니다.

  • 디자인 제약: 모든 페이지가 공통의 논리적 구조를 따르므로, 개별 페이지의 독창적인 디자인을 구현하기 어렵습니다. 디자인의 유연성이 제한될 수 있습니다.

Two Step View의 활용 사례: Two Step View는 대규모 웹 애플리케이션에서 일관된 디자인을 유지하면서 여러 페이지를 관리해야 할 때 적합합니다. 예를 들어, 온라인 쇼핑몰에서는 제품 목록 페이지, 장바구니 페이지, 결제 페이지 등 다양한 페이지가 있지만, 모두 동일한 스타일과 레이아웃을 공유해야 합니다. 이 경우 Two Step View를 사용하여 중앙에서 디자인을 관리할 수 있습니다.

Application Controller

Application Controller는 응용 프로그램의 흐름을 중앙에서 관리하는 패턴입니다. 복잡한 웹 애플리케이션에서는 화면 간의 이동이나 사용자 상태에 따른 화면 전환 로직이 중요합니다. Application Controller는 이러한 흐름 제어를 중앙에서 관리하여 코드 중복을 줄이고, 응용 프로그램의 유지보수성을 높입니다.

Application Controller의 동작 방식:

  • 명령 및 뷰 관리: Application Controller는 도메인 명령과 뷰를 중앙에서 관리합니다. 사용자의 요청에 따라 어떤 명령을 실행할지, 어떤 뷰를 보여줄지를 결정합니다. 이를 위해 Application Controller는 명령 객체와 뷰에 대한 참조를 유지합니다.

  • 상태 기반 흐름 제어: Application Controller는 응용 프로그램의 상태에 따라 화면 흐름을 제어할 수 있습니다. 예를 들어, 사용자가 특정 상태에 있을 때만 특정 화면으로 이동할 수 있도록 제한할 수 있습니다.

  • 메타데이터 기반 제어: Application Controller는 상태 기계(state machine)로서 동작할 수 있으며, 메타데이터를 사용하여 화면 간의 흐름을 제어할 수 있습니다.

Application Controller의 장점:

  • 코드 중복 감소: 응용 프로그램의 흐름 제어 로직을 중앙에서 관리하기 때문에, 여러 화면에서 동일한 로직이 반복되는 것을 방지할 수 있습니다. 이는 코드 중복을 줄이고 유지보수를 쉽게 만듭니다.

  • 복잡한 흐름 관리: 복잡한 화면 흐름을 효과적으로 관리할 수 있습니다. 예를 들어, 여러 단계로 이루어진 폼 입력 과정이나 사용자 상태에 따른 화면 전환을 쉽게 구현할 수 있습니다.

  • 테스트 용이성: Application Controller는 UI와 독립적으로 동작할 수 있기 때문에, UI와 분리된 상태에서 독립적으로 테스트할 수 있습니다.

Application Controller의 단점:

  • 구현 복잡성: Application Controller는 중앙에서 모든 흐름을 관리하기 때문에, 구현이 복잡해질 수 있습니다. 특히, 상태 기계를 설계하고 관리하는 데 있어 복잡성이 증가할 수 있습니다.

  • UI 종속성: Application Controller는 응용 프로그램의 특정 UI에 종속될 수 있습니다. 이로 인해 다른 UI(예: 웹, 모바일)로의 이식성이 낮아질 수 있습니다.

Application Controller의 활용 사례: Application Controller는 화면 간의 이동이 복잡한 웹 애플리케이션에서 유용합니다.

예를 들어, 온라인 금융 애플리케이션에서는 사용자가 특정 조건을 만족할 때만 특정 화면으로 이동할 수 있어야 합니다. 이 경우 Application Controller를 사용하여 이러한 흐름을 중앙에서 관리할 수 있습니다. 또한, 다중 단계로 이루어진 프로세스(예: 회원 가입 과정)를 관리할 때도 유용합니다

Previous객체 관계형 구조 패턴Next분산 패턴

Last updated