모델-뷰-뷰모델

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. MVVM 패턴의 구성 요소
3. MVVM 패턴의 역사
4. MVVM 패턴의 장점
5. MVVM 패턴의 단점
6. MVVM 패턴 구현체
- 6.1. 닷넷 프레임워크
- 6.2. 자바스크립트 프레임워크
참조

1. 개요

모델-뷰-뷰모델(MVVM) 패턴은 사용자 인터페이스(UI) 개발을 위한 아키텍처 패턴으로, 모델, 뷰, 뷰 모델의 세 가지 구성 요소로 이루어진다. 뷰는 사용자에게 보이는 UI의 구조와 모양을 정의하고, 뷰 모델은 뷰에 표시할 데이터를 준비하고 사용자 입력을 처리한다. 모델은 애플리케이션의 데이터와 비즈니스 로직을 담당한다. MVVM은 뷰와 뷰 모델 간의 데이터 바인딩을 통해 뷰 계층의 코드를 줄이고, 개발자와 디자이너의 역할 분담을 용이하게 한다. 마이크로소프트의 존 고스만이 2005년에 처음 소개했으며, WPF, 실버라이트, XAML 기반 환경에서 주로 사용된다. MVVM은 데이터 바인딩과 프레임워크를 활용하여 데이터 유효성 검사를 수행하고, 애플리케이션 로직을 최소화하는 장점이 있지만, 단순한 UI 작업에는 과도할 수 있으며, 뷰 모델의 비대화 및 순환 참조 문제가 발생할 수 있다. 닷넷 프레임워크, 자바스크립트 프레임워크 등 다양한 환경에서 MVVM 패턴을 구현하는 라이브러리 및 프레임워크가 존재한다.

더 읽어볼만한 페이지

닷넷 용어 - XAML
XAML은 마이크로소프트에서 개발한 XML 기반의 마크업 언어로, 사용자 인터페이스, 데이터 바인딩, 이벤트 처리 등을 정의하며 WPF, Silverlight, WF, WinRT API 앱, Xamarin.Forms 등에서 UI 개발에 널리 사용된다.
닷넷 용어 - 윈도우 커뮤니케이션 파운데이션
윈도우 커뮤니케이션 파운데이션(WCF)은 마이크로소프트가 분산 시스템 개발을 용이하게 하고 서비스 지향 아키텍처(SOA)를 구현하기 위해 개발한 프레임워크로, 다양한 전송 프로토콜과 메시지 인코딩 방식을 지원하며 닷넷 프레임워크 3.0의 일부로 출시되어 다양한 유형의 애플리케이션 통합을 목표로 한다.
아키텍처 패턴 - 서비스 지향 아키텍처
서비스 지향 아키텍처(SOA)는 기능들을 독립적인 서비스 단위로 분리하여 느슨하게 결합함으로써, 네트워크를 통해 접근 가능한 서비스를 재사용하고 결합하여 응용 프로그램을 구축하는 소프트웨어 아키텍처이다.
아키텍처 패턴 - 제어 반전
제어 반전은 프로그램의 제어 흐름을 프레임워크나 컨테이너가 관리하도록 하는 프로그래밍 원칙으로, 코드 결합도를 낮추고 유연성을 높이지만, 복잡성을 증가시킬 수 있다는 비판도 존재한다.
소프트웨어 디자인 패턴 - 모델-뷰-컨트롤러
모델-뷰-컨트롤러(MVC)는 소프트웨어 디자인 패턴으로, 응용 프로그램을 모델, 뷰, 컨트롤러 세 가지 요소로 분리하여 개발하며, 사용자 인터페이스 개발에서 데이터, 표현 방식, 사용자 입력 처리를 분리해 유지보수성과 확장성을 높이는 데 기여한다.
소프트웨어 디자인 패턴 - 스케줄링 (컴퓨팅)
스케줄링은 운영 체제가 시스템의 목적과 환경에 맞춰 작업을 관리하는 기법으로, 장기, 중기, 단기 스케줄러를 통해 프로세스를 선택하며, CPU 사용률, 처리량 등을 기준으로 평가하고, FCFS, SJF, RR 등의 알고리즘을 사용한다.

모델-뷰-뷰모델
개요
종류	소프트웨어 아키텍처 디자인 패턴
상세 정보
목적	사용자 인터페이스 로직을 비즈니스 로직과 분리
관련 패턴	모델-뷰-컨트롤러 (MVC) 프레젠테이션 모델 (PM)
적용 분야	.NET WPF UWP Xamarin Forms JavaScript KnockoutJS ZK

2. MVVM 패턴의 구성 요소

모델은 실제 상태 내용을 표현하는, 도메인 모델을 참조하거나 (이는 객체-지향 접근법이라 한다), 또는 내용을 표현하는, 데이터 접근 계층을 참조한다. (이는 데이터-중심 접근법이라 한다).^[34]

모델-뷰-컨트롤러(MVC)와 모델-뷰-프리젠터(MVP) 패턴에서와 같이, 뷰는 사용자가 화면에서 보는 것들에 대한 구조, 배치, 그리고 외관에 해당한다.^[34] 모델을 보여서 표현하고 사용자와 뷰의 상호 작용(클릭, 키보드, 동작 등)을 수신하여, 이에 대한 처리를 뷰와 뷰 모델의 연결을 정의하고 있는 (속성, 이벤트 콜백 함수 등의) 데이터 바인딩(data binding, 데이터 연결)을 통하여 뷰 모델로 전달한다.

뷰 모델은 공용 속성과 공용 명령을 노출하는 뷰에 대한 추상화(abstraction)이다. MVC 패턴의 컨트롤러나, MVP 패턴의 프리젠터(presenter, 발표자)를 대신하여, MVVM은 바인더(binder, 연결자)를 가지고 있는데, 이는 뷰 모델에 있는 뷰에 연결된 속성과 뷰 사이의 통신을 자동화 한다. 뷰 모델은 모델에 있는 데이터의 상태라고 설명했었다.^[35]

뷰 모델과 MVP 패턴에 있는 프리젠터 사이의 주요한 차이점은 프리젠터는 뷰에 대한 참조를 가지고 있는 반면, 뷰 모델은 그렇지 않다는 것이다. 그 대신, 뷰는 뷰 모델의 속성에 직접 '연결된(binds)' 채로 업데이트를 주고 받는다. 효율적으로 작동하려면, '바인딩 기술(binding technology, 연결 기술)' 또는 '바인딩'을 하는 상용구 코드 (boilerplate code)의 자동 생성이 필수이다.^[34]

MVVM 패턴에서는 선언적인 데이터와 '명령-바인딩(명령-연결)'이 내재되어 있다. 마이크로소프트 솔루션 스택에서, 바인더는 XAML이라는 마크업 언어이다.^[36] 바인더는 뷰 모델과 뷰의 동기화를 위해 상용구 로직을 작성해야 하는 의무에서 개발자를 해방시켜 준다. 마이크로소프트 스택을 사용하지 않고 구현한다면, '선언적인 데이터 바인딩 기술' 이 있어야 이 패턴을 만들 수 있으며,^[32]^[37] 바인더가 없다면, 그 대신 일반적인 MVP 나 MVC를 사용해야 할 것이고 더 많은 상용구 코드를 작성하게 (아니면 이를 다른 도구로 생성하게) 될 것이다.

2. 1. 모델 (Model)

모델은 애플리케이션의 데이터와 비즈니스 로직을 담당한다. 데이터베이스, 웹 서비스, 파일 등으로부터 데이터를 가져오고, 데이터를 처리하고 가공하는 역할을 수행한다. 모델은 뷰나 뷰모델에 대해 알지 못하며, 독립적으로 작동한다. 모델은 실제 상태 내용을 표현하는 도메인 모델을 참조하거나(객체 지향 접근법), 내용을 표현하는 데이터 액세스 계층을 참조한다(데이터 중심 접근법).

대부분의 애플리케이션에서는 데이터 저장을 위해 영구적인 기억 장치 (데이터베이스 등)를 사용하거나, 서버가 별도로 존재하는 애플리케이션에서는 서버 측과의 통신 로직 등이 포함되어 있다. 모델-뷰-컨트롤러(MVC) 개념과 마찬가지로, 데이터의 (UI 이외의) 입출력은 다루지 않으므로, 굳이 말하자면, 그것들은 Model 안에 숨겨져 있다고 생각할 수 있다.

일반적으로 Model은 도메인을 담당한다고 하지만, 이 말만으로는 Model의 역할을 상상하기 어렵다. 예를 들어, 클라이언트-서버 모델의 애플리케이션 클라이언트 측은 해당 도메인 자체가 프레젠테이션이 된다. 애플리케이션을 프레젠테이션과 도메인으로 나누어 생각하려 할 때, 이 점이 혼란의 원인이 된다. Model의 역할은, View와 ViewModel의 역할 이외의 부분이라고 생각하는 것이 타당하다.

Model은 View의 렌더링에 대해 알지 못하며, 알 필요도 없다. 여기서 중요한 것은, Model은 렌더링에 관여하지 않을 뿐, View의 외형, 장식에 대한 정보를 보관하는 것은 MVVM 패턴으로서 아무런 문제가 없다는 것이다. 즉, 해당 애플리케이션이 배경색이나 글자색, 컨트롤 간의 여백과 같은 표시를 사용자 정의할 수 있는 경우, 그 배경색이나 글자색, 여백의 크기를 보관하는 것은 Model이다. 다만, 앞서 언급했듯이 Model은 렌더링에는 관여하지 않으며, 그 정보를 바탕으로 실제로 렌더링하는 것은 View의 역할이다. (물론 이 Model의 정보는 ViewModel을 거쳐 바인딩된다.)

2. 2. 뷰 (View)

모델-뷰-컨트롤러 (MVC) 및 모델-뷰-프레젠터 (MVP) 패턴과 마찬가지로, '''뷰'''는 사용자가 화면에서 보는 것의 구조, 레이아웃 및 모양이다.^[6] 뷰는 모델의 표현을 표시하고 사용자의 뷰와의 상호 작용 (마우스 클릭, 키보드 입력, 화면 탭 제스처 등)을 수신하며, 뷰와 뷰 모델을 연결하도록 정의된 데이터 바인딩 (속성, 이벤트 콜백 등)을 통해 이러한 처리를 뷰 모델로 전달한다. 뷰 모델은 모델의 데이터 상태로 설명되어 왔으며,^[7] 뷰 모델과 MVP 패턴의 프레젠터 간의 주요 차이점은 프레젠터는 뷰에 대한 참조를 갖는 반면 뷰 모델은 그렇지 않다는 것이다.^[6] 대신, 뷰는 뷰 모델의 속성에 직접 바인딩하여 업데이트를 보내고 받는다.^[6]

'''뷰'''(View)는 애플리케이션이 다루는 데이터를 사용자가 보기 적합한 형태로 표시하고, 사용자로부터 입력을 받는 요소이다. 즉, 사용자 인터페이스의 입출력이 책임이다. 뷰는 선언적으로 정의되며^[24], 전달된 값을 기반으로 렌더링을 수행하고, 사용자 입력을 알린다. 따라서 MVVM에서의 뷰는 상태를 가지지 않는다.

구현에서는 종종 뷰모델과의 데이터 바인딩을 통해 값의 획득과 렌더링·사용자 입력의 알림이 이루어진다. 따라서 템플릿 엔진이나 선언형 도메인 특화 언어 (DSL)에 뷰를 위임하는 형태의 플랫폼과 매우 잘 맞는다.

MVVM은 Model-View-Controller(MVC)에서 파생된 아키텍처이며, 몇 가지 차이점이 있다.

먼저 MVVM의 '''View는 MVC에서의 Controller를 포함'''한다. 이는 현대 GUI 플랫폼이 Controller가 예전에 담당했던 작업의 대부분을 추상화했으며, thin Controller를 굳이 구분할 필요성이 낮기 때문이다^[25].

또한 MVVM의 '''View는 선언적으로 정의되고 상태를 가지지 않는다'''. MVC에서의 View는 상태를 가진 View 클래스였으며, Model에는 포함되지 않은 View용 상태(View State. 예: UI 전환 중임을 나타내는 속성)를 보관했다. MVVM에서 이 책임은 뷰모델로 옮겨졌으며, View는 UI의 정의와 값의 매핑에만 책임을 갖는다^[26].

2. 3. 뷰 모델 (View Model)

뷰 모델은 공용 속성과 공용 명령을 노출하는 뷰에 대한 추상화(abstraction)이다.^[7] 뷰 모델은 모델의 데이터 상태로 설명되어 왔다.^[7] 뷰 모델은 MVC 패턴의 컨트롤러 또는 MVP 패턴의 프레젠터와 다르게 뷰에 대한 참조를 갖지 않는다. 대신, 뷰는 뷰 모델의 속성에 직접 바인딩하여 업데이트를 보내고 받는다. 이를 효율적으로 수행하려면 바인딩 기술이 필요하거나 바인딩을 수행하기 위해 보일러플레이트 코드를 생성해야 한다.^[6] 객체 지향 프로그래밍에서 뷰 모델은 때때로 데이터 전송 객체라고도 한다.^[8]

뷰 모델은 뷰를 그리기 위한 상태를 유지하고, 뷰로부터 받은 입력을 적절한 형태로 변환하여 모델에 전달하는 역할을 한다. 즉, 뷰와 모델 사이의 정보 전달과 뷰를 위한 상태 유지만을 역할로 하는 요소이다. 구현에서는 종종 뷰와의 통신을 데이터 바인딩 기법과 같은 메커니즘을 통해 수행한다. 그 경우 뷰 모델의 변경 사항은 개발자 입장에서 볼 때 자동으로 뷰에 반영된다.

2. 4. 바인더 (Binder, 연결자)

MVVM 패턴에는 선언적인 데이터와 '명령-바인딩(명령-연결)'이 내재되어 있다.^[9] 바인더는 XAML과 같은 마크업 언어를 통해 뷰와 뷰 모델 간의 데이터 동기화를 자동화한다.^[9] 이는 개발자가 직접 동기화 관련 코드를 작성하는 수고를 덜어준다.^[4]^[10] 바인더가 없는 환경에서는 일반적으로 MVP나 MVC 패턴을 대신 사용하고 더 많은 보일러플레이트 코드를 작성해야 한다.^[4]^[10]

3. MVVM 패턴의 역사

마이크로소프트 MVP인 조쉬 스미스의 보고서에 따르면, 2005년 마이크로소프트의 WPF 및 실버라이트 아키텍트였던 존 고스만이 자신의 블로그에서 모델-뷰-뷰모델(MVVM) 패턴을 발표했다. 고스만은 사용자 인터페이스 작성을 간소화하기 위해 WPF의 핵심 기능에 대한 표준화된 방법으로 MVVM을 도입했다.

MVVM 패턴은 2006년 11월 21일에 출시된 .NET Framework 3.0에 구현된 WPF와 실버라이트를 지원하기 위해 고안되었다. MVVM은 MVC나 MVP 패턴 등 다른 패턴의 영향을 받아 발전해왔다.

창시자인 존 고스만, 마이크로소프트 MVP인 조쉬 스미스, 마이크로소프트 프로그램 매니저인 칼 쉬플렛은 MVVM에 대해 온라인에서 폭넓게 정보를 공개하고 있다.

4. MVVM 패턴의 장점

MVVM 패턴은 윈도 프리젠테이션 파운데이션(WPF)의 데이터 바인딩 기능을 활용하여 뷰 계층에서 GUI 코드 ("코드 비하인드")를 최대한 제거하고, 뷰 계층 개발을 패턴의 나머지 부분과 분리한다.^[3] 이를 통해 사용자 경험(UX) 개발자는 GUI 코드를 직접 작성하는 대신 프레임워크 마크업 언어(예: XAML)를 사용하여 뷰 모델에 대한 데이터 바인딩을 생성할 수 있다. 뷰 모델은 애플리케이션 개발자가 작성하고 관리한다. 이러한 역할 분리는 상호 작용 설계자가 비즈니스 로직 프로그래밍보다는 UX 요구 사항에 집중할 수 있도록 해주며, 애플리케이션 계층별로 개발 흐름을 여러 개로 나누어 생산성을 높일 수 있다.^[31] 단일 개발자가 전체 코드 기반에서 작업하는 경우에도, 사용자 인터페이스는 최종 사용자의 피드백에 따라 개발 주기 후반에 자주 변경되기 때문에 모델과 뷰를 적절히 분리하는 것이 더 생산적이다.

MVVM 패턴은 MVC가 제공하는 기능적 개발 분리의 장점과 데이터 바인딩 및 프레임워크의 장점을 활용하여 데이터를 가능한 한 순수한 애플리케이션 모델에 가깝게 바인딩하려고 시도한다.^[3]^[11]^[12] 바인더, 뷰 모델 및 비즈니스 레이어의 데이터 확인 기능을 사용하여 들어오는 데이터를 검증하며, 모델과 프레임워크가 가능한 한 많은 작업을 수행하여 뷰를 직접 조작하는 애플리케이션 로직을 최소화하거나 제거한다.^[38]^[39]

5. MVVM 패턴의 단점

MVVM 패턴의 제작자인 존 구스만(John Gossman)은 단순한 UI 작업에는 MVVM 구현이 "지나치게 과하다"고 지적한다.^[40] 애플리케이션이 커질수록 뷰 모델을 광범위하게 사용하기 어려워지며, 대규모 애플리케이션에서 데이터 바인딩은 메모리 소모를 증가시킨다.^[40]^[13]

뷰모델은 모델-뷰 간의 형태를 맞추기 위한 변환과 값 유지를 담당하며, 모델 변환 연산을 수행한다. 하지만 모델이 담당해야 할 연산까지 뷰모델에서 구현하는 경우가 발생하며, 이러한 구현 실수와 비대화는 팻 뷰모델(Fat ViewModel)이라고 불린다. 뷰에서도 명령 발행 연산만 수행해야 하지만, 명령 인수 계산 과정 등에서 비즈니스 로직을 포함하는 구현 오류가 발생할 수 있다.

하나의 모델과 뷰를 중재하기 위해 뷰모델이 존재하지만, 구현상 다른 뷰모델에서 이를 이용하는 경우가 있다. 예를 들어 VM1의 값이 다른 뷰모델(VM2)에서도 사용 가능한 형태로 정형화되어 있다면, VM2는 변환 구현 없이 VM1을 참조, 감시하여 값을 얻을 수 있다. 하지만 VM1이 VM2의 값을 참조하면 순환 참조가 발생한다. VM1은 VM2의 값 변경을 감시하므로, VM2의 변경으로 VM1이 변경되고, 다시 VM2가 변경되는 루프가 발생하여 시스템 상태를 예측하기 어려워진다.

6. MVVM 패턴 구현체

6. 1. 닷넷 프레임워크

Prism Library, Caliburn / Caliburn.Micro, DevExpress MVVM, DotVVM, MVVMLight Toolkit, ReactiveUI, Mugen MVVM Toolkit, Uno Framework, Rascl, MvvmCross 등은 닷넷 프레임워크에서 MVVM 패턴을 구현하는 데 사용되는 라이브러리 및 프레임워크이다. .NET 커뮤니티 툴킷, Avalonia, Chinook.DynamicMvvm, FreshMvvm, Jellyfish, MvvmZero, Xamlcc 등도 MVVM 패턴을 지원한다.

WPF, Silverlight, Windows 런타임(WinRT) (특히 유니버설 Windows 플랫폼(UWP)), Xamarin.Forms와 같은 XAML 기반 환경에서 주로 사용된다.

6. 2. 자바스크립트 프레임워크

앵귤러, 리액트, Vue.js, [https://aurelia.io Aurelia], [http://durandaljs.com/ Durandal], Ember.js, Ext JS, Knockout.js, [https://github.com/Tencent/omi/blob/master/tutorial/omi-mvvm.md Omi.js], [http://www.oracle.com/webfolder/technetwork/jet/index.html Oracle JET], Svelte는 모델-뷰-뷰모델 패턴을 따르는 자바스크립트 프레임워크이다.^[27]

참조

_[1] 웹사이트 Thought: MVVM eliminates 99% of the need for ValueConverters https://groups.googl[...]
_[2] 웹사이트 The Presentation Model Design Pattern http://martinfowler.[...] Martin Fowler.com 2004-07-19
_[3] 논문 WPF Apps with the Model–View–ViewModel Design Pattern http://msdn.microsof[...] 2009-02
_[4] 웹사이트 Presentation Patterns in ZK http://www.slideshar[...] 2012-03-24
_[5] 웹사이트 KnockoutJS http://knockoutjs.co[...]
_[6] 웹사이트 The MVVM Pattern https://msdn.microso[...] 2016-08-29
_[7] 웹사이트 Model–View–ViewModel Pattern for WPF: Yet another approach. http://www.acceptede[...]
_[8] 웹사이트 Tutorial: Create a web API with ASP.NET Core https://learn.micros[...] 2024-04-03
_[9] 웹사이트 Windows Presentation Foundation Data Binding: Part 1 http://msdn.microsof[...] Microsoft 2012-03-24
_[10] 웹사이트 ZK MVVM http://books.zkoss.o[...] Potix 2012-03-24
_[11] 웹사이트 Tales from the Smart Client: Introduction to Model/View/ViewModel pattern for building WPF apps https://docs.microso[...] 2005-10-08
_[12] 웹사이트 Learning WPF M-V-VM. http://karlshifflett[...] 2009-06-05
_[13] 논문 Tales from the Smart Client: Advantages and disadvantages of M-V-VM https://docs.microso[...] 2006-03-04
_[14] 문서 "Model/View/ViewModel is ... tailored for modern UI development platforms" Gossman (2005). original post.
_[15] 웹사이트 PresentationModel http://martinfowler.[...] 2012-04-12
_[16] 문서 "In short, the UI part of the application is being developed using different tools, languages and by a different person than is the business logic or data backend." Gossman (2005). original post.
_[17] 문서 "In simple examples, the View is data bound directly to the Model. ... Other parts of the model can be edited by directly binding controls two-way to the data." Gossman (2005). original post.
_[18] 문서 "In practice however, only a small subset of application UI can be data bound directly to the Model" Gossman (2005). original post.
_[19] 문서 "The Model is very likely to have a data types that cannot be mapped directly to controls. The UI may want to perform complex operations that must be implemented in code which doesn't make sense in our strict definition of the View but are too specific to be included in the Model" Gossman (2005). original post.
_[20] 문서 "Finally we need a place to put view state such as selection or modes." Gossman (2005). original post.
_[21] 문서 "Model/View/ViewModel is thus a refinement of MVC that evolves it '''from''' its Smalltalk origins where the entire application was built using one environment and language, '''into''' the very familiar modern environment ..." Gossman (2005). original post.
_[22] 문서 "The term means 'Model of a View'" Gossman (2005). original post.
_[23] 문서 it also provides a specialization of the Model that the View can use for data-binding. In this latter role the ViewModel contains data-transformers that convert Model types into View types, and it contains Commands the View can use to interact with the Model. Gossman (2005). original post.
_[24] 문서 "The View is almost always defined declaratively" Gossman (2005). original post.
_[25] 문서 "The View ... consists of ... controls of a GUI. ... '''controls themselves manage the interaction with the input devices that is the responsibility of Controller in MVC''' (what exactly happened to Controller in modern GUI development is a long digression...I tend to think it just faded into the background. It is still there, but we don't have to think about it as much as we did in 1979)." Gossman (2005). original post.
_[26] 문서 "By the nature of ... declarative languages some '''view state that MVC encodes in its View classes''' is not easy to represent. For example, the UI may have multiple modes of interaction such as "view mode" and "edit mode" that change the behavior of the controls or the look of the visuals, but these modes can't always be expressed in XAML" Gossman (2005). original post.
_[27] 문서 "MVVM パターンに厳密に関連づけられているわけではないにもかかわらず、Vue の設計は部分的にその影響を受けています。慣例的に、私たちはインスタンスを参照するのに変数 vm（ViewModel の短縮形）を使用します。" Vue.js v3. [https://v3.ja.vuejs.org/guide/instance.html#%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9%E3%81%AE%E4%BD%9C%E6%88%90 docs].
_[28] 문서 "多くのネイティブアプリ開発者にとって親しみやすいモデル-ビュー-ビューモデル (MVVM: Model-View-ViewModel) パターンを踏襲しています。" [https://docs.microsoft.com/ja-jp/archive/msdn-magazine/2017/september/asp-net-core-simpler-asp-net-mvc-apps-with-razor-pages ASP.NET Core - Razor ページを使った簡単な ASP.NET MVC アプリ].
_[29] 웹인용 Thought: MVVM eliminates 99% of the need for ValueConverters https://groups.googl[...]
_[30] 웹인용 The Presentation Model Design Pattern http://martinfowler.[...] Martin Fowler.com 2004-07-19
_[31] 논문 WPF Apps with the Model-View-ViewModel Design Pattern http://msdn.microsof[...] 2009-02
_[32] 웹인용 Presentation Patterns in ZK http://www.slideshar[...] 2012-03-24
_[33] 웹인용 KnockoutJS http://knockoutjs.co[...]
_[34] 웹인용 The MVVM Pattern https://msdn.microso[...] 2016-08-29
_[35] 웹인용 Model-View-ViewModel Pattern for WPF: Yet another approach. http://www.acceptede[...]
_[36] 웹인용 Windows Presentation Foundation Data Binding: Part 1 http://msdn.microsof[...] Microsoft 2012-03-24
_[37] 웹인용 ZK MVVM http://books.zkoss.o[...] Potix 2012-03-24
_[38] 저널 Tales from the Smart Client: Introduction to Model/View/ViewModel pattern for building WPF apps http://blogs.msdn.co[...]
_[39] 웹인용 Learning WPF M-V-VM. http://karlshifflett[...] 2009-06-05
_[40] 저널 Tales from the Smart Client: Advantages and disadvantages of M-V-VM https://docs.microso[...]

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com