MVVM은 무의미합니까?
정통 MVVM 구현은 무의미합니까?새 응용프로그램을 만드는 중이며 Windows Forms와 WPF를 고려했습니다.미래에 대비하고 유연성이 뛰어나기 때문에 WPF를 선택했습니다.XAML을 사용하면 코드가 적고 UI를 크게 변경하기가 쉽습니다.
WPF를 선택하는 것이 확실하기 때문에 MVVM을 애플리케이션 아키텍처로 사용하면 혼합성, 분리 문제 및 장치 테스트 가능성을 제공할 수 있을 것이라고 생각했습니다.이론적으로는 UI 프로그래밍의 성배처럼 아름답습니다.하지만 이 짧은 모험은 정말 골치 아픈 일로 변했습니다.실제로 예상했던 대로, 저는 한 가지 문제를 다른 문제와 교환했다는 것을 알게 되었습니다.저는 강박적인 프로그래머인 경향이 있습니다. 올바른 방법으로 일을 처리하여 올바른 결과를 얻고 더 나은 프로그래머가 되고 싶기 때문입니다.MVVM 패턴은 생산성에 대한 제 테스트에 실패했고 이제 막 엄청난 해킹으로 변했습니다!
Modal(모달) 대화 상자에 대한 지원을 추가하는 것이 좋은 예입니다.올바른 방법은 대화 상자를 표시하고 뷰 모델에 연결하는 것입니다.이것을 작동시키는 것은 어렵습니다.MVVM 패턴을 활용하려면 응용 프로그램의 여러 계층에 코드를 배포해야 합니다.또한 템플릿 및 람바 표현식과 같은 난해한 프로그래밍 구조를 사용해야 합니다.머리를 긁적이며 화면을 응시하게 만드는 것들.이로 인해 유지보수 및 디버깅은 최근에 알게 된 악몽처럼 계속 발생합니다.대화 상자가 닫히면 대화 상자를 다시 표시할 수 없다고 말하면서 두 번째로 호출할 때까지 약 상자가 정상적으로 작동했습니다.대화창에 닫기 기능을 위한 이벤트 핸들러를 추가해야 했습니다. IDialogView 구현에 있는 이벤트 핸들러와 IDialogView 모델에 있는 이벤트 핸들러를 추가해야 했습니다.MVVM이 그런 사치스러운 해킹으로부터 우리를 구해줄 것이라고 생각했습니다!
이 문제에 대한 경쟁적인 해결책을 가진 사람들이 몇 명 있지만, 그들은 모두 엉터리이며 깨끗하고 쉽게 재사용할 수 있는 우아한 해결책을 제공하지 않습니다.대부분의 MVVM 툴킷은 대화상자에 글로스오버(glossover) 기능을 제공하며, 대화상자를 해결할 때 사용자 지정 인터페이스나 뷰 모델이 필요 없는 알림 상자에 불과합니다.
저는 MVVM 뷰 패턴, 적어도 정통적인 구현은 포기할 계획입니다.당신은 어떻게 생각하나요?당신이 고생한 보람이 있었습니까?제가 그저 무능한 프로그래머인가요, 아니면 MVVM이 과장된 것이 아닌가요?
내 대답이 조금 길어졌다면 미안하지만, 나를 탓하지 마!당신의 질문도 길어요.
요약하자면, MVVM은 무의미하지 않습니다.
Modal(모달) 대화 상자에 대한 지원을 추가하는 것이 좋은 예입니다.올바른 방법은 대화 상자를 표시하고 뷰 모델에 연결하는 것입니다.이것을 작동시키는 것은 어렵습니다.
네, 정말 그렇습니다.
그러나 MVVM은 UI의 모양과 논리를 구분하는 방법을 제공합니다.아무도 모든 곳에서 사용하도록 강요하지 않으며, 모든 것에 대해 별도의 뷰 모델을 만들도록 총을 이마에 대고 있지도 않습니다.
다음은 이 특정 예제에 대한 제 솔루션입니다.
UI가 특정 입력을 처리하는 방식은 View Model과 무관합니다.대화 상자를 인스턴스화하고 DataContext와 동일한 ViewModel 인스턴스(또는 필요한 경우 다른 인스턴스)를 설정하는 View의 .xaml.cs 파일에 코드를 추가합니다.
MVVM 패턴을 활용하려면 응용 프로그램의 여러 계층에 코드를 배포해야 합니다.또한 템플릿 및 람바 표현식과 같은 난해한 프로그래밍 구조를 사용해야 합니다.
글쎄요, 여러 곳에서 사용할 필요는 없습니다.이것이 제가 해결할 방법입니다.
- XAML을 View에 추가하고 .xaml.cs 에는 아무것도 추가하지 않습니다.
- View Model 내의 모든 애플리케이션 로직(UI 요소와 직접 작동하는 로직 제외) 작성
- UI에서 수행해야 하지만 비즈니스 로직과 관련이 없는 모든 코드는 .xaml.cs 파일로 들어갑니다.
MVVM의 목적은 주로 애플리케이션의 로직과 구체적인 UI를 분리하여 UI를 쉽게 수정(또는 완전히 교체)할 수 있도록 하는 것이라고 생각합니다.
다음 원칙을 사용합니다. 보기는 보기 모델에서 원하는 모든 것을 알고 가정할 수 있지만 보기 모델은 보기에 대해 아무것도 알 수 없습니다.
WPF는 정확하게 이를 달성하는 데 사용할 수 있는 멋진 바인딩 모델을 제공합니다.
(BTW, 템플릿 및 람다 식을 올바르게 사용하면 난해하지 않습니다.하지만 당신이 원하지 않으면, 그것들을 사용하지 마세요.)
머리를 긁적이며 화면을 응시하게 만드는 것들.
네, 그 느낌 알아요.MVVM을 처음 봤을 때 바로 그 느낌이었습니다.하지만 일단 요령을 터득하면 더 이상 기분이 나쁘지 않을 것입니다.
한 박스 정도는 잘 작동했습니다...
정보 상자 뒤에 View Model을 배치하는 이유는 무엇입니까?그것은 의미가 없습니다.
대부분의 MVVM 툴킷은 대화상자에 글로스오버(glossover) 기능을 제공하며, 대화상자를 해결할 때 사용자 지정 인터페이스나 뷰 모델이 필요 없는 알림 상자에 불과합니다.
예, UI 요소가 현재 동일한 창이나 다른 창에 있거나 화성 궤도를 돌고 있다는 사실 자체가 ViewModels의 관심사가 아니기 때문입니다.
우려의 분리
편집:
여기 아주 멋진 비디오가 있습니다. 제목은 "나만의 MVVM 프레임워크 구축"입니다.볼만한 가치가 있습니다.
이것을 작동시키는 것은 어렵습니다.MVVM 패턴을 활용하려면 응용 프로그램의 여러 계층에 코드를 배포해야 합니다.또한 템플릿 및 람바 표현식과 같은 난해한 프로그래밍 구조를 사용해야 합니다.
일반적인 모달 대화 상자의 경우?MVVM 구현이 그렇게 복잡할 필요는 없습니다.
MVVM과 WPF 모두 처음 사용하는 고객이라는 점을 고려할 때, 모든 곳에서 차선의 솔루션을 사용하고 불필요하게 복잡한 작업을 수행하고 있을 가능성이 높습니다. 적어도 처음 WPF에 갔을 때는 그렇게 했습니다.단념하기 전에 문제가 구현이 아닌 MVVM에 있는지 확인합니다.
MVVM, MVC, Document-View 등은 오래된 패턴 계열입니다.단점은 있지만, 당신이 설명한 종류의 치명적인 결함은 없습니다.
저는 PRISM을 사용하여 상당히 복잡한 MVVM 개발을 진행 중이어서 이미 이러한 문제에 대처해야 했습니다.
제 개인적인 결론은:
MVVM 대 MVC/PopUps&co
- MVVM은 정말 훌륭한 패턴이며 대부분의 경우 WPF의 강력한 데이터 바인딩 덕분에 MVC를 완전히 대체합니다.
- 대부분의 경우 프레젠터에서 직접 서비스 계층을 호출하는 것은 합법적인 구현입니다.
- {BindingPath=/} 구문 덕분에 상당히 복잡한 목록/세부 정보 시나리오도 순수 MVVM에 의해 구현될 수 있습니다.
- 그럼에도 불구하고 여러 뷰 간의 복잡한 조정을 구현해야 하는 경우 컨트롤러는 필수입니다.
- 이벤트를 사용할 수 있습니다. IView(또는 AbstractObserver) 인스턴스를 컨트롤러에 저장하는 것을 의미하는 이전 패턴은 사용되지 않습니다.
- 컨트롤러는 IOC 컨테이너를 통해 각 발표자에게 주입할 수 있습니다.
- Prism의 IEeventAggregator 서비스는 컨트롤러의 유일한 용도가 이벤트 디스패치(이 경우 컨트롤러를 완전히 대체할 수 있음)인 경우에도 가능한 솔루션입니다.
- 뷰가 동적으로 생성되는 경우 컨트롤러에 매우 적합한 작업입니다(프리즘에서 컨트롤러는 IOC(IRegionManager) 주입됨).
- 모달 대화 상자는 필수 확인과 같은 실제 차단 작업을 제외하고는 현대의 복합 애플리케이션에서 대부분 쓸모가 없습니다. 이러한 경우 모달 활성화는 컨트롤러 내부에서 호출되는 서비스로 추상화되고 전문 클래스에 의해 구현될 수 있으며, 고급 프레젠테이션 수준의 유닛 테스트도 가능합니다.예를 들어 컨트롤러는 IC Confirmation Service를 호출합니다.실행 시 모달 대화 상자 표시를 트리거하고 장치 테스트 중에 쉽게 조롱할 수 있는 RequestConfirmation("Are you sure")
저는 대화 문제를 부정행위로 처리합니다.My MainWindow는 모든 응용 프로그램별 대화 상자를 표시하는 IWindowServices 인터페이스를 구현합니다.그러면 다른 ViewModel이 서비스 인터페이스(MEF를 사용하지만, 생성자를 통해 인터페이스를 수동으로 쉽게 전달할 수 있음)를 가져와서 필요한 작업을 수행할 수 있습니다.예를 들어, 작은 유틸리티 애플리케이션을 위한 인터페이스는 다음과 같습니다.
//Wrapper interface for dialog functionality to allow for mocking during tests
public interface IWindowServices
{
bool ExecuteNewProject(NewProjectViewModel model);
bool ExecuteImportSymbols(ImportSymbolsViewModel model);
bool ExecuteOpenDialog(OpenFileDialog dialog);
bool ExecuteSaveDialog(SaveFileDialog dialog);
bool ExecuteWarningConfirmation(string text, string caption);
void ExitApplication();
}
이렇게 하면 모든 Dialog 실행이 한 곳에 배치되고 장치 테스트를 위해 쉽게 스텁아웃할 수 있습니다.대화상자의 클라이언트가 적절한 View Model을 생성하고 필요에 따라 구성하는 패턴을 따릅니다.Execute call block 후 클라이언트는 View Model의 내용을 보고 Dialog 결과를 볼 수 있습니다.
보다 '순수한' MVVM 설계는 더 깨끗한 절연과 더 복잡한 구성이 필요한 대규모 애플리케이션에서는 중요할 수 있지만, 중소 규모 애플리케이션에서는 필요한 후크를 노출할 수 있는 적절한 서비스를 제공하는 실용적인 접근 방식으로 충분하다고 생각합니다.
디자인 패턴은 방해가 아니라 여러분을 돕기 위해 존재합니다.훌륭한 개발자가 되기 위한 작은 부분은 "규칙을 어기는" 시기를 아는 것입니다.MVVM이 작업에 번거롭고 미래의 가치가 노력할 가치가 없다고 판단한 경우에는 패턴을 사용하지 마십시오.예를 들어, 다른 포스터가 언급한 것처럼 간단한 정보 상자를 구현하기 위해 모든 간접비를 사용하는 이유는 무엇입니까?
디자인 패턴은 절대 독단적으로 따르도록 의도되지 않았습니다.
패턴 자체가 MVVM이 좋기 때문입니다.그러나 NET 4.0 데이터 바인딩 지원과 함께 제공되는 WPF의 제어 라이브러리는 매우 제한적이며 WinForm보다 훨씬 우수하지만 바인딩 가능한 MVVM에는 아직 충분하지 않습니다. 바인딩 가능한 MVVM에 필요한 전력의 약 30%입니다.
바인딩 가능한 MVVM: View Model이 데이터 바인딩만을 사용하여 View와 연결되는 UI입니다.
MVVM 패턴은 ViewState의 개체 표현에 관한 것이며, ViewModel과 ViewModel 간의 동기화를 유지하는 방법을 설명하지 않으며, WPF에서는 데이터 바인딩이지만 무엇이든 될 수 있습니다.또한 의 이벤트\콜백을 지원하는 UI 툴킷에서 MVVM 패턴을 사용할 수 있으며 WinForms의 순수 WinAPI에서도 사용할 수 있습니다(제가 사용했습니다. 이벤트\콜백 작업은 더 이상 수행할 필요가 없습니다). 또한 텍스트 콘솔에서도 MVVM 패턴을 사용하여 DoS의 Norton Commander를 다시 쓰는 것과 같이 사용할 수 있습니다.
간단히 말해서 MVVM은 무의미한 것이 아니라 훌륭합니다.NET 4.0 WPF의 제어 라이브러리는 휴지통입니다.
다음은 WPF를 사용하여 순수 MVVM 방식으로 데이터를 바인딩할 수 없는 간단한 개념 증명 ViewModel입니다.
public class PersonsViewModel
{
public IList<Person> PersonList;
public IList<ColumnDescription> TableColumns;
public IList<Person> SelectedPersons;
public Person ActivePerson;
public ColumnDescription SortedColumn;
}
WPF의 DataGrid 열 헤더를 데이터 바인딩할 수 없고, 선택한 행을 데이터 바인딩할 수 없는 등의 작업을 코드 단순한 방법으로 수행하거나, 가장 단순한 ViewModel의 5줄에 대해 200줄의 XAML 해킹 코드를 작성할 수 있습니다.복잡한 View 모델을 사용하면 상황이 어떻게 악화되는지 상상만 할 수 있습니다.
따라서 Hello World 애플리케이션을 작성하는 경우가 아니라면 WPF에서 바인딩 가능한 MVVM을 사용하는 것은 무의미합니다.ViewModel을 바인딩하기 위해 대부분의 시간을 해킹에 할애할 것입니다.데이터 바인딩은 좋지만 이벤트의 70% 시간으로 되돌아갈 준비가 되어 있습니다.
아니요, 의미가 없는 것은 아니지만, 무늬 자체가 터무니없이 단순한데도 머리를 싸매는 것은 어렵습니다.잘못된 정보가 넘쳐나고 적절한 방법을 놓고 싸우는 다양한 단체들이 있습니다.WPF와 Silverlight를 사용하면 MVVM을 사용해야 합니다. 그렇지 않으면 새로운 모델에서 문제를 해결하려고 시도하는 "오래된" Winforms 방법론이 문제를 일으키게 될 것입니다.Silverlight에서는 모든 것이 비동기식이어야 하기 때문에 더욱 그렇습니다(이를 둘러싼 해킹은 가능하지만 다른 플랫폼을 선택하는 것이 좋습니다).
이 기사 View Model Pattern을 사용하여 WPF Tree View를 단순화하는 방법을 주의 깊게 읽어보고 MVVM을 잘 구현할 수 있는 방법과 MVVM에서 새로운 사고 방식으로 Winforms 사고 방식을 변경할 수 있는 방법을 확인해 보는 것이 좋습니다.간단히 말해서, 작업을 수행하려는 경우 논리를 뷰가 아닌 뷰 모델에 먼저 적용합니다.항목을 선택하시겠습니까?아이콘을 변경하시겠습니까?UI 요소를 반복하지 말고 모델 속성을 업데이트하고 데이터 바인딩을 사용하면 됩니다.
(모달) 대화 상자와 관련하여 많은 MVVM 구현에서 동일한 문제를 보았습니다.MVVM 패턴의 참가자들을 보면 일관성 있는 애플리케이션을 구축하기에는 뭔가 부족하다는 느낌이 듭니다.
- 보기에는 특정 GUI 컨트롤이 포함되어 있으며 사용자 인터페이스의 모양을 정의합니다.
- View Model은 프레젠테이션의 상태와 동작을 나타냅니다.
- 모델은 도메인 계층의 비즈니스 개체이거나 필요한 데이터를 제공하는 서비스일 수 있습니다.
그러나 누락된 것은 다음과 같습니다.
- View Model은 누가 생성합니까?
- 애플리케이션 워크플로우는 누가 담당합니까?
- View 모델 간에 서로 통신이 필요할 때 누가 조정합니까?
제 접근 방식은 누락된 지점을 담당하는 (사용 사례) 컨트롤러를 도입하는 것입니다.WPF(WPF Application Framework) 샘플 애플리케이션에서 이 기능을 확인할 수 있습니다.
언급URL : https://stackoverflow.com/questions/2798447/is-mvvm-pointless
'programing' 카테고리의 다른 글
| 시스템 트레이에 대한 앱 최소화 (0) | 2023.04.27 |
|---|---|
| bash 스크립트에서 사용자에게 확인 메시지를 표시하려면 어떻게 해야 합니까? (0) | 2023.04.27 |
| Angular 버전을 얻는 방법은 무엇입니까? (0) | 2023.04.27 |
| Swift: 0에 대한 옵션 테스트 (0) | 2023.04.27 |
| "GatherAllFilesToPublish 대상이 존재하지 않습니다" 오류가 표시되는 이유는 무엇입니까? (0) | 2023.04.27 |