MVVM을 사용해야 하는 이유
저는 MVVM 패턴을 조사해 왔습니다. 이전에 조사해 본 적이 있을 때마다 다음과 같은 이유로 포기했습니다.
- 불필요한 여분의 긴 권선 코딩
- 코더에게는 명백한 이점이 없습니다(제 사무실에는 디자이너가 없습니다).현재는 곧 다른 코더가 될 나 자신뿐입니다.)
- 우수 관리 기준에 대한 자료/문서가 많지 않음! (적어도 찾기가 어렵거나)
- 이것이 유리한 단일 시나리오를 생각할 수 없습니다.
저는 다시 그것을 포기하려고 합니다, 그리고 위의 이유들에 대해 누군가가 대답하는지 물어보려고 생각했습니다.
저는 솔직히 이것을 단일/파트너 코딩에 사용하는 것이 이점이라고 생각하지 않습니다.10개의 창이 있는 복잡한 프로젝트에서도 마찬가지입니다.데이터셋은 브렌트가 다음 질문에 답한 것처럼 충분히 보기 좋고 구속력이 있습니다.
XAML DataBinding과 비교하여 MVVM 패턴을 사용하면 시간이 절약되는 예를 보여줄 수 있습니까?
현재 제 바인딩의 100%는 XAML에서 이루어집니다.따라서 VM의 요점을 기록하고 의존해야 하는 추가 코드로 보지 않습니다.
오후에 MVVM에 대해 조사한 결과, 이 답변을 통해 MVVM의 진정한 이점을 알게 된 것입니다.
요약
- 모든 패턴의 사용은 상황에 따라 다르며, 이점(있는 경우)은 항상 복잡성 감소에 있습니다.
- MVVM은 GUI 응용 프로그램에서 클래스 간에 책임을 분산하는 방법을 안내합니다.
- 뷰 모델은 모델의 데이터를 뷰에 적합한 형식으로 투영합니다.
- 사소한 프로젝트의 경우 MVVM이 필요하지 않습니다.보기만 사용하면 됩니다.
- 단순 프로젝트의 경우 View Model/Model 분할이 불필요할 수 있으며, Model과 View를 사용하는 것만으로도 충분합니다.
- 모델 및 뷰 모델은 처음부터 존재할 필요가 없으며 필요할 때 도입할 수 있습니다.
패턴을 사용할 때와 피할 때
충분히 단순한 응용 프로그램의 경우 모든 설계 패턴이 오버킬입니다.누르면 "Hello world"가 표시되는 단일 버튼을 표시하는 GUI 응용 프로그램을 작성한다고 가정합니다.이 경우 MVC, MVP, MVVM과 같은 설계 패턴은 모두 많은 복잡성을 증가시키면서도 아무런 가치도 추가하지 않습니다.
일반적으로 어느 정도 들어맞는다고 해서 디자인 패턴을 도입하는 것은 항상 나쁜 결정입니다.설계 패턴은 전체 복잡성을 직접 줄이거나 익숙하지 않은 복잡성을 익숙한 복잡성으로 대체하여 복잡성을 줄이는 데 사용해야 합니다.설계 패턴이 이 두 가지 방법 중 하나로 복잡성을 줄일 수 없는 경우에는 사용하지 마십시오.
익숙하고 익숙하지 않은 복잡성을 설명하기 위해 다음 두 개의 문자 시퀀스를 사용합니다.
- "D.€|레%dfa?c"
- "올바른 말 배터리 스테이플"
두 번째 문자 시퀀스는 첫 번째 시퀀스의 두 배 길이이지만, 첫 번째 시퀀스보다 읽기 쉽고, 쓰기 쉽고, 기억하기 쉽습니다. 모두 더 친숙하기 때문입니다.코드에서 익숙한 패턴에 대해서도 마찬가지입니다.
익숙함이 독자에게 달려 있다는 것을 고려할 때 이 문제는 또 다른 차원을 얻습니다.일부 독자들은 위의 비밀번호보다 "3.141592653589323846264337950"을 기억하는 것이 더 쉽다는 것을 알게 될 것입니다.안 하는 사람도 있어요.따라서 MVVM 버전을 사용하려면 사용 중인 특정 언어와 프레임워크에서 가장 일반적인 형식을 미러링하는 버전을 사용해 보십시오.
MVVM
즉, MVVM에 대한 주제를 예를 들어 살펴보겠습니다.MVVM은 소수의 클래스를 유지하면서 클래스당 책임 수를 작고 잘 정의된 상태로 유지하는 것을 목표로 GUI 애플리케이션의 클래스 간(또는 계층 간)에 책임을 분산하는 방법을 안내합니다.
'적절한' MVVM은 "어디선가" 얻은 데이터를 처리하는, 적어도 중간 정도로 복잡한 애플리케이션을 가정합니다.데이터베이스, 파일, 웹 서비스 또는 수많은 다른 소스에서 데이터를 가져올 수 있습니다.
예
에서는 두 클래스가 .View그리고.Model하지만 아닙니다ViewModel.Model시작할 때 읽은 CSV 파일을 래핑하고 응용 프로그램이 종료될 때 사용자가 데이터를 변경한 모든 내용과 함께 저장합니다. 그View는 데터를표시 Window의 입니다.Model사용자가 데이터를 편집할 수 있습니다.다음과 수 . csv 컨 텐 표 있 수 니 습 다
ID, Name, Price
1, Stick, 5$
2, Big Box, 10$
3, Wheel, 20$
4, Bottle, 3$
새로운 요구 사항:유로로 가격 표시
이제 우리는 우리의 애플리케이션을 변경해야 합니다.데이터는 이미 "가격" 열이 있는 2차원 그리드로 구성되며 가격은 USD로 표시됩니다.우리는 미리 정의된 환율을 기준으로 USD 가격 외에 유로 가격을 표시하는 새로운 열을 추가해야 합니다.다른 응용 프로그램은 동일한 파일로 작동하고 이러한 다른 응용 프로그램은 당사의 통제 하에 있지 않으므로 csv-file 형식을 변경해서는 안 됩니다.
한능해단새열로추것다입니는에 입니다.Model해결책이 . 업수. 이것은 최선의 해결책이 아닙니다. 왜냐하면Model합니다. csv에 하는 것은 .그래서 그 변화는Model단순하지 않을 뿐만 아니라 코드 냄새인 모델 클래스가 수행하는 작업을 설명하기가 더 어려울 수도 마찬가지입니다.
우리는 또한 변화를 만들 수 있습니다.View 현재 합니다.Model 프레임워크에서는 이 데이터 소스에 바인딩된 때된 열을 수 에 클스래를 . 테이블이 데이터 소스에 바인딩된 경우 GUI 프레임워크에서 테이블에 추가로 계산된 열을 도입할 수 없기 때문에 테이블을 크게 변경해야 합니다.View이 일을 하기 위해서, 만들기 위해서.View훨씬 더 복잡합니다.
View 모델 소개
.ViewModel애플리케이션에서 왜냐하면 지금까지.Model로 하는 하며, 는 Csv의 . 이는 또한View필요했습니다.가지고 있는 것.ViewModel목적 없이 복잡성이 더해졌을 것입니다하지만 이제는Model를 더이데를제않습다니공지하 .View는 필해요씁, 는니다리우를 .ViewModel는 의 데이터를 단순한 방식으로 투영합니다.이전 버전View에 한 학급.Model 업수. 이제 새로운ViewModel과 같이 합니다.Model클래스, 그리고 공개합니다.Model의 데이터를 에 전송합니다.View가격이 유로로 표시된 추가 열이 있습니다. 그View더 이상 알 수 없는Model이제 그것은 오직 그것만 압니다.ViewModel그것은 그의 관점에서.View와 동일하게 보입니다.Model노출된 데이터에 새 읽기 전용 열이 포함되어 있는 경우를 제외하고 이전에 수행했습니다.
새로운 요구 사항: 데이터를 포맷하는 다른 방법
다음 고객 요청은 데이터를 표에 행으로 표시하지 말고 각 항목(예: 행)의 정보를 카드/상자로 표시하고 화면에 상자 20개를 4x5 그리드로 표시하여 한 번에 20개의 상자를 표시하는 것입니다.왜냐하면 우리는 논리를 지켰기 때문입니다.View단순하게, 우리는 간단히 교체합니다.View전적으로 고객이 원하는 대로 하는 새로운 클래스로.물론 오래된 것을 선호하는 다른 고객도 있습니다.View그래서 우리는 이제 둘 다 지원해야 합니다.모든 일반적인 비즈니스 논리가 이미 실행되고 있기 때문입니다.ViewModel그것은 큰 문제가 아닙니다.보기 클래스의 이름을 다음으로 변경하여 이 문제를 해결할 수 있습니다.TableView그리고 새로운 것을 쓰는 것.CardView데이터를 카드 형식으로 표시하는 클래스입니다.우리는 또한 글루 코드를 작성해야 할 것이고, 이것은 시작 기능의 하나의 줄일지도 모릅니다.
새로운 요구사항: 동적 환율
다음 고객 요청은 미리 정의된 환율을 사용하는 것이 아니라 인터넷에서 환율을 끌어내는 것입니다.이것이 "계층"에 대한 제가 이전에 말한 내용을 다시 검토하는 지점입니다.▁changet'▁we를 바꾸지 않습니다.Model환율을 제공하는 클래스입니다.대신 환율을 제공하는 완전히 독립적인 추가 클래스를 작성(또는 찾습니다)합니다.레이어의 , 의 그새운클계모층일되의고부가의리,우는델로래스.ViewModel는 를 통합한 csv-Model에 합니다.View이 변경을 위해 이전 모델 클래스와 보기 클래스를 터치할 필요가 없습니다.는 모델 의 이름을 이다름변음로합경니야다해으을모델래의로 바꿔야 합니다.CsvModel그리고 우리는 새로운 반을 부릅니다.ExchangeRateModel.
해야 하기 Model을 이 더 입니다.View 리고그고.Model을 을다로이니다합동으로 이동합니다.ViewModel.
유닛 테스트의 뒷말
MVVM의 주요 목적은 모델 및 보기 모델의 코드를 단위 테스트에 넣을 수 있다는 것이 아닙니다.MVVM의 주요 목적은 코드가 소수의 잘 정의된 책임을 가진 클래스로 분할되는 것입니다.소수의 잘 정의된 책임이 있는 클래스로 구성된 코드의 여러 이점 중 하나는 코드를 단위 테스트에 더 쉽게 넣을 수 있다는 것입니다.훨씬 더 큰 이점은 코드를 이해, 유지 및 수정하기 쉽다는 것입니다.
패턴을 구현하고 모범 사례를 따르는 것은 종종 무의미한 추구처럼 느껴지지만, 몇 달 후 상사가 기능을 추가하거나 수정하라고 요청하면 전환자가 될 것입니다.MVVM(일반적인 패턴 포함)을 사용하면 실제로 자체 코드를 따라 몇 주 또는 몇 개월이 아닌 몇 시간 또는 며칠 만에 요구 사항을 충족할 수 있습니다.(이러한 변경은 새 기능을 추가하기도 전에 처음에 수행한 작업을 파악하는 데 몇 주를 소비하기보다는 코드 몇 줄만 사용하는 것에 불과할 수 있습니다.)
후속 조치: 패턴과 모범 사례는 실제로 초기 개발을 지연시킬 것이며, 이는 종종 경영진과 엔지니어링 모두에게 어려운 일입니다.투자 회수(비즈니스 측면에서 ROI)는 실제로 유지 관리, 확장 및 확장이 가능한 잘 구조화된 코드를 보유함으로써 발생합니다.
예를 들어 MVVM을 제대로 따르면 데이터 및 비즈니스 로직에 영향을 주지 않으면서 전체 뷰를 스왑하는 등 디스플레이 로직을 매우 획기적으로 변경할 수 있습니다.
당신의 모델에 데이터셋을 사용하는 것에 대한 생각: (저도 사실 이것에 빠져 있습니다.)데이터 세트는 애플리케이션에서 모델 데이터를 이동하는 데 완벽하게 유효한 방법인 것 같습니다.문제는 데이터 항목을 식별하는 방법에 있습니다.데이터가 행과 열에 저장되므로 열 이름이나 인덱스를 기준으로 조회를 수행하고 특정 행을 필터링해야 합니다.이러한 논리 비트는 응용 프로그램의 배선 논리에서 마법의 문자열과 숫자를 사용해야 한다는 것을 의미합니다.입력된 데이터 세트를 사용하면 이 문제가 일부 완화되지만 완전히 해결되지는 않습니다.입력된 데이터 세트를 사용하면 MVVM에서 벗어나 UI와 데이터 소스 간의 결합이 더욱 강화됩니다.
GUI와 프로그램 로직을 구분하는 데 도움이 됩니다. 이들을 혼합하면 특히 프로젝트가 시간이 지남에 따라 증가할 때 애플리케이션을 유지 관리하기가 매우 어려울 수 있습니다.
여기서:
개발자로서 모델-뷰-뷰 모델 패턴에 관심을 가져야 하는 이유는 무엇입니까?이러한 패턴은 WPF 및 Silverlight 개발 모두에 여러 가지 이점을 제공합니다.계속하기 전에 다음과 같이 자문해 보십시오.
- 설계자와 프로젝트를 공유하고 설계 작업과 개발 작업을 거의 동시에 수행할 수 있는 유연성이 필요합니까?
- 귀사의 솔루션에 대해 철저한 유닛 테스트가 필요합니까?
- 재사용 가능한 구성요소를 조직 내 및 프로젝트 간에 모두 보유하는 것이 중요합니까?
- 코드 기반의 다른 로직을 리팩터링하지 않고 사용자 인터페이스를 더 유연하게 변경하시겠습니까?
이러한 질문에 "예"라고 대답한 경우 MVVM 모델을 사용하면 프로젝트에 몇 가지 이점이 있을 뿐입니다.
- 디자이너(프로그래머가 아니라 블렌드를 사용하는 사람)와 함께 작업하는 것이 더 쉽습니다.
- 코드 테스트 가능(단위 테스트)
- 코드의 나머지 부분을 조작하지 않고 보기를 변경하는 것이 훨씬 쉽습니다.
- UI를 개발하는 동안 실제 서비스를 실행하지 않고도 모의 모델링 및 인터페이스를 개발할 수 있습니다(모델의 모의 데이터만 사용).그런 다음 플래그를 뒤집고 서비스에 연결하면 됩니다.
MVVM을 애플리케이션을 자연스럽게 구성하는 WPF(및 Silverlight 2) 기능 외에도 ViewModel 클래스는 단위 테스트가 쉽기 때문에 패턴도 인기가 있습니다.응용 프로그램의 상호 작용 논리가 ViewModel 클래스 집합에 있는 경우 이를 테스트하는 코드를 쉽게 작성할 수 있습니다.보기와 단위 테스트는 어떤 의미에서 View Model 소비자의 두 가지 다른 유형에 불과합니다.애플리케이션의 View Model에 대한 일련의 테스트를 통해 자유롭고 빠른 회귀 테스트를 수행할 수 있으며, 이를 통해 애플리케이션 유지 관리 비용을 절감할 수 있습니다.
저는 이것이 MVVM을 사용하는 가장 중요한 이유입니다.
이전에는 뷰 모델과 뷰 모델을 함께 통합하는 컨트롤이 있었습니다.그러나 뷰에는 기본적으로 마우스 및 키보드 이벤트가 입력으로, 픽셀이 출력으로 표시됩니다.어떻게 유닛 테스트를 하나요?MVVM은 테스트할 수 없는 보기와 테스트할 수 있는 보기 모델을 분리하고 보기 계층을 가능한 한 얇게 유지하기 때문에 이 문제를 해결합니다.
MVVM에는 여러 가지 좋은 점이 있지만, 가장 중요한 것은 코드를 테스트하는 기능(ViewModel을 테스트하는 장치)입니다.
뷰 모델과 뷰 모델 간의 연결 부족은 느슨한 결합에도 도움이 됩니다.코딩한 구성 요소를 재사용하는 것이 매우 쉬워집니다.
이 기사에서 MVVM에 대한 소개를 읽어보십시오.
2005년, 현재 마이크로소프트의 WPF 및 실버라이트 설계자 중 한 명인 John Gossman은 자신의 블로그에서 모델-뷰-뷰 모델(MVVM) 패턴을 공개했습니다.MVVM은 두 패턴 모두 뷰의 상태와 동작을 포함하는 뷰의 추상화를 특징으로 한다는 점에서 Fowler의 프레젠테이션 모델과 동일합니다.Fowler는 UI 플랫폼에 의존하지 않는 View 추상화를 생성하는 수단으로 Presentation Model을 도입한 반면 Gossman은 사용자 인터페이스 생성을 단순화하기 위해 WPF의 핵심 기능을 활용하는 표준화된 방법으로 MVVM을 도입했습니다.그런 의미에서 MVVM은 WPF 및 Silverlight 플랫폼에 맞게 제작된 보다 일반적인 PM 패턴의 전문화라고 생각합니다.
..
MVP의 프레젠터와 달리 View Model은 뷰에 대한 참조가 필요하지 않습니다.뷰는 뷰 모델의 속성에 바인딩되며, 이는 모델 개체 및 뷰 관련 기타 상태에 포함된 데이터를 표시합니다.ViewModel 개체가 뷰의 DataContext로 설정되어 있으므로 뷰와 ViewModel 간의 바인딩은 구성할 수 있습니다.View Model의 속성 값이 변경되면 이러한 새 값이 데이터 바인딩을 통해 뷰에 자동으로 전파됩니다.사용자가 View에서 버튼을 클릭하면 View Model의 명령이 실행되어 요청된 작업을 수행합니다.보기가 아닌 보기 모델은 모델 데이터에 대한 모든 수정 작업을 수행합니다.뷰 클래스는 모델 클래스가 존재하는지 알 수 없지만 뷰 모델 및 모델은 뷰를 알 수 없습니다.실제로 모델은 뷰 모델과 뷰가 존재한다는 사실을 완전히 인식하지 못합니다.이것은 매우 느슨하게 결합된 디자인으로, 여러분이 곧 보실 것처럼 다양한 방식으로 배당금을 지급합니다.
또한 이 문서에서는 이러한 GUI 패턴을 사용하는 이유에 대해 설명합니다.
간단한 "Hello, World!" 프로그램에서 디자인 패턴을 사용하는 것은 불필요하고 비생산적입니다.유능한 개발자라면 누구나 코드 몇 줄을 한 눈에 이해할 수 있습니다.그러나 프로그램의 피쳐 수가 증가함에 따라 코드 줄 수와 움직이는 부품 수가 증가합니다.결국, 시스템의 복잡성과 시스템에 포함된 반복적인 문제는 개발자들이 이해, 토론, 확장 및 문제 해결이 더 쉬운 방식으로 코드를 구성하도록 장려합니다.소스 코드의 특정 엔티티에 잘 알려진 이름을 적용하여 복잡한 시스템의 인지 혼돈을 줄입니다.우리는 시스템에서 코드의 기능적 역할을 고려하여 코드 조각에 적용할 이름을 결정합니다.
개발자들은 종종 패턴이 유기적으로 나타나도록 하는 것과 반대로 디자인 패턴에 따라 코드를 의도적으로 구성합니다.두 접근 방식 모두 잘못된 것은 아니지만, 이 기사에서는 MVVM을 WPF 애플리케이션의 아키텍처로 명시적으로 사용할 경우의 이점을 살펴봅니다.특정 클래스의 이름에는 MVVM 패턴의 잘 알려진 용어가 포함됩니다. 예를 들어 클래스가 뷰의 추상화인 경우 "ViewModel"로 끝납니다.이 접근법은 앞에서 언급한 인지적 혼란을 방지하는 데 도움이 됩니다.대신, 여러분은 대부분의 전문적인 소프트웨어 개발 프로젝트에서 자연스러운 상황인 통제된 혼돈 상태에서 행복하게 살 수 있습니다!
저는 여전히 그 패턴을 이해하고 있지만, 저는 그것이 가치 있다고 생각합니다.현재 가장 큰 문제는 접근 방식이 여전히 상당히 새로운 것이기 때문에 많은 혼란이 있으며 패턴의 특정 핵심 구성 요소는 여전히 구현하기가 어색하다는 것입니다.패턴을 더 깨끗하게 구현하는 데 큰 도움이 되는 몇 가지를 발견했습니다.
Josh Smith의 MVVM Foundation에서 제공하는 Relay Command를 많이 사용하고 있습니다.이렇게 하면 명령을 통해 보기에서 보기 모델로 바인딩하는 작업이 훨씬 깔끔해집니다.
AOP를 사용하여 INOTIFY 구현 시 발생하는 문제를 완화합니다.속성이 변경되었습니다.저는 현재 Postsharp를 사용하고 있지만, 이를 수행할 수 있는 다른 도구가 있다고 생각합니다.만약 제가 이것을 발견하지 못했다면, 저는 아마 지금쯤 포기했을 것입니다. 수동으로 구현하기 위한 상용 코드가 저를 정말 괴롭혔기 때문입니다.
저는 소프트웨어가 어떻게 구현되는지에 대한 접근 방식을 전환해야 했습니다.내 소프트웨어는 모든 부하들에게 무엇을 해야 하는지 알려주는 독재자 클래스가 아니라 다음과 같은 느슨하게 결합된 서비스의 문제가 됩니다.
이것이 내가 할 줄 아는 방법입니다.
이것들이 제가 해야 할 일들입니다.
이러한 방식으로 코드를 구성하기 시작하고 종속성을 쉽게 연결할 수 있는 도구를 사용할 때(선택할 수 있는 다양한 IoT 프레임워크가 있음) MVVM의 어색함을 어느 정도 덜어준다는 것을 알게 되었습니다.View 모델에 모델을 주입하고 View 모델이 사용할 다양한 View 서비스(예: 파일 대화 상자 표시)를 찾는 것과 관련된 상용 코드를 줄일 수 있습니다.
이러한 다양한 접근 방식을 학습하는 것은 엄청난 투자이며, 구현의 큰 변화와 마찬가지로 처음 사용할 때 생산성이 훨씬 떨어집니다.하지만, 저는 터널 끝에 약간의 빛이 보이기 시작했고, 지저분한 세부 사항을 숙지하고 나면 애플리케이션이 더 깨끗하고 훨씬 더 유지 관리가 가능할 것이라고 생각합니다.
INOTIFY에 대한 질문을 해결하기포스트샤프를 통해 속성이 변경되었습니다. 여기에 있는 예를 바탕으로 Aspect를 사용합니다.저는 제 용도에 맞게 약간 커스터마이징을 했지만, 요점을 알 수 있습니다.이것으로, 저는 그냥 수업에 태그를 붙입니다 [알림]PropertyChanged] 및 모든 공용 속성은 자동 속성 설정자인 경우에도 해당 설정자에서 구현된 패턴을 가집니다.더 이상 시간을 내서 수업을 시행해야 할지 고민할 필요가 없기 때문에 훨씬 깔끔해 보입니다.속성이 변경되었습니다.속성을 추가하면 됩니다.
다른 사람들이 올린 모든 이유로 MVVM과 같은 패턴을 사용하면 장기적으로 행복할 것입니다.패턴 요구 사항을 한 글자 한 글자 따를 필요 없이 창(보기)과 논리(코드백)를 잘 구분해야 합니다.
저는 MVVM을 사용하는 것이 광맥 코드를 작성함으로써 우리의 어깨에 더 많은 무게를 두는 것에 동의합니다. 하지만 만약 당신이 디자이너라면, 당신이 프로그램을 디자인하고 다른 사람들이 그것을 코딩할 수 있고, 다른 사람들은 당신을 위해 데이터베이스 레이어를 코딩할 수 있습니다.특히 대규모 엔터프라이즈 애플리케이션에서 MVVM을 사용하지 않을 경우 얼마나 유지 보수가 가능한 환경이 될 것인지 살펴봅니다.저도 ERP 솔루션을 개발할 때 사용한 적이 있습니다. 격리 수준 때문에 유지보수가 상당히 간단합니다.
MVVM의 이점
- 복잡성 감소.
- 설계 및 개발의 격리.
- 종속성 주입.
- 주요 장점은 Windows Phone 애플리케이션이 잘 MVVM 구조화되어 있고 Windows Metro Desktop용으로 동일하게 개발하려는 경우 동일한 뷰 모델로 설계에 집중하고 싶은 것만 그대로 사용할 수 있다는 것입니다.
도움이 되길 바랍니다.
MVVM은 정말 과도한 코드입니다.
그렇다면 MVVM은 어떤 이점을 제공합니까?
걱정의 분리일 뿐이지 더 이상은 아닙니다.View Model 로직을 컨트롤러에 쓸 수도 있습니다.View Model은 변환(예: 객체를 문자열로)만 수행할 수 있습니다.MVVM을 사용하면 객체 지향 프로그래밍 스타일을 더 많이 사용할 수 있습니다.변환 로직을 컨트롤러에 기록하면 보다 기능적인 프로그래밍 스타일을 사용할 수 있습니다.
따라서 읽기 쉬운 코드가 더 많거나 큰 컨트롤러 파일이 있는 코드가 더 적은 것으로 귀결됩니다.결론적으로 MVVM을 사용해야 한다고 말할 수 없습니다. MVC 등보다 더 낫기 때문에 개인적인 선호일 뿐입니다.
컨트롤러를 언급한 이유를 확실히 하기 위해 MVVM에도 컨트롤러 코드가 있습니다.나는 왜 C를 떠나는 것에 대한 폭넓은 합의가 있는지 모르겠습니다.
언급URL : https://stackoverflow.com/questions/2653096/why-use-mvvm
'programing' 카테고리의 다른 글
| sudo로 두 개의 명령을 실행하는 방법은 무엇입니까? (0) | 2023.05.09 |
|---|---|
| .classpath 및 .project - 버전 제어에 체크인하시겠습니까? (0) | 2023.05.04 |
| 마지막 커밋을 실행 취소하는 방법 (0) | 2023.05.04 |
| 배열의 첫 번째 항목에서 일치하도록 MongoDB 쿼리 (0) | 2023.05.04 |
| TypeError 가져오기: __init_() 항목이 있는 하위 테이블 뒤에 상위 테이블을 추가할 때 필요한 위치 인수 'on_delete'가 하나 누락되었습니다. (0) | 2023.05.04 |