한 번은 MVVM / WPF 프로젝트를 시작했는데, 이는 결국 구축 및 배포되었으며이를 위해 Caliburn.Micro MVVM 프레임 워크를 많이 연구했습니다. 사실은 Caliburn.Micro를 사용하지 않고 결국 일부 MVVM 개념을 구현했습니다 (특히 ViewModelBase 및 RoutedCommand 클래스).
이제 동일한 라인을 따라 다소 큰 프로젝트에 배정되었습니다. ” 단일 사용자 리치 클라이언트 오프라인 데스크톱 애플리케이션 “, 말하자면 Caliburn.Micro를 사용하기로 결정했습니다. 이것이 바로 제 ” 문제 “가 시작되는 곳입니다.
이 유명한 블로그 게시물 , 제목에 ” MVVM을 사용하는 경우 프레임 워크 “가 필요합니다.
” 프레임 워크없이 MVVM과 같은 작업을 수행하는 것은 엄청난 작업입니다. 수많은 중복 코드, 재창조, 사람들이 다르게 생각하도록 재교육합니다 .
적어도 중복 코드를 피하고 바퀴를 재발 명 할 필요가없는 프레임 워크로 사람들을 재교육하는 데 집중할 수 있습니다. 재교육 부분은 일반적으로 피할 수 없지만 프레임 워크는 배관 코드와 구조를 제공하여 프로세스를 더 쉽게 만듭니다. ”
처음 읽기에 동의하지만 Caliburn.Micro (CM)에 대한 실제 경험 내 실제 응용 프로그램에서 우둔함과 방향 감각 상실이 있습니다. 즉, 프레임 워크는 프로세스를 전혀 쉽게 만들지 않았습니다. 그 반대입니다. Rob Eisenberg가 비공식적 인 문서에서 제공하는 계속 반복되는 예제를 읽고 복잡한 제공된 샘플에서 사용 패턴을 추론하려고합니다. 부작용에 대해 기반 으로 작동하도록 설계된 것처럼 보이는 완전히 간접적 인 클래스 및 인터페이스 관계는 노련한 천재가 아니라면 인간적으로 불가능 해 보입니다 (폭언을해서 죄송합니다. 내 말은).
위의 사소한 시나리오가 IoC 컨테이너와 관련이있는 것 같음은 말할 것도없고, 내가 사용해 본 적이없고 내가 가지지 못할 수도있는 문제를 해결합니다. 내 문제와 애플리케이션 도메인에 대해 생각하는 대신 이러한 것들을 배우는 데 더 많은 프로젝트 시간을 소비하고 싶지 않습니다. 그냥 바나나를 원했지만 CM이 바나나 바구니를 들고있는 고릴라 (IoC)를주었습니다.
이제 몇 개의 MVVM으로 만 구성된 집에서 만든 MVVM 프레임 워크로 돌아가는 것을 고려하고 있습니다. 실제로 구현하고 싶은 특정 클래스-여기에서 무언가를 잃어 버리거나 명백하게 일을 ” 잘못된 방식으로
순수한 경험과 무지. 그래서 질문은 다음과 같습니다.
” 프레임 워크가 일을 더 쉽고 자연스럽게 만든다는 데 널리 동의하고 있습니다. ” 그러나 정반대의 상황이 발생한다면 프레임 워크를 사용하지 않아야하거나 잘못된 방법으로 배우려고한다는 의미입니까? 처음부터 프레임 워크를 사용해서는 안된다는 단서? 아니면 간단한 MVVM 개발에 CM을 사용하는 방법을 알아내는 ” 올바른 ” 방법이 있습니까?
댓글
Answer
CaliburnMicro 및 MVVMLight를 사용해 보았습니다. Caliburn을 사용할 때 정말 느낌이 듭니다. Name = ” PropertyName ” 이전 Text = ” {Bind PropertyName} ” 대신 Caliburn은이 마법 같은 일을하기 위해 배 밖으로 나갑니다. . 뭔가 잘못되면 디버깅하기가 정말 어렵고 상황을 악화시키기 위해 한 가지를 수행 할 수있는 많은 방법이 있습니다.
반대로 MVVMLight는 정말 얇습니다. 이를 사용하면 MVVM 프레임 워크와 거의 100 % 유사하며 일부 기능이 뿌려져 있음을 알게 될 것입니다.
이것이 귀하의 질문에 대한 답변이 아님을 압니다. ” 프레임 워크를 사용하지 않는 방법 “하지만 솔직히이 경로를 추천 할 수는 없습니다. 먼저 간단한 프레임 워크를 사용하는 대신 완전한 기능을 갖춘 프레임 워크를 사용했기 때문에 길을 잃은 것 같습니다.
댓글
- 그럼, 적어도 MVVMLight를 ” div에서 ” 치료 “의 일종으로 사용해야합니다. > Caliburn.Micro 방향 감각 상실 “? 그렇다면 꼭 한번 살펴 보겠습니다.
- @heltonbiker 물론입니다. 최소한 MVVM 프레임 워크에 대한 좋은 발판을 제공한다면 훨씬 더 간단합니다.
- 너무 많은 마법이 진행되고 있다는 데 동의합니다. C 및 어셈블리 배경에서 온 것 같습니다. E 무언가가 ‘ 백그라운드의 마술로 인해 작동하지 않는다는 것을 알게되었습니다. 디버그가 불가능하고 성능 문제가 자주 발생하지 않는 경우 쉽게 해결할 수 있습니다.
답변
MVVM이 무엇인지 깨닫는 것이 중요합니다. 재 구현 (JPEG 파일 구문 분석 또는 주어진 SQL 데이터베이스 서버에 연결) 할 필요가없는 일부 공유 기능이 아니라 선택 방법에 대한 패턴 인 패턴 입니다. 풍부한 GUI를 구현합니다. 따라서 패턴의 구현이 간단하고 간단하다면 프레임 워크가 아닌 사용에 대해 부끄러워 할 필요가 없다고 생각합니다.
사실, 전체 패턴을 프레임 워크로 구현 한 아이디어는 너무 멀리 갔다. 패턴이 되려면 솔루션 클래스의 일반적인 모양이어야합니다. 그렇기 때문에 패턴을 사용하는 시스템에 맞게 패턴을 조정해야 할 것으로 예상되며 한 가지 크기의 모든 패턴을 사용하려고하면 그렇게 할 수 없습니다. 패턴 구현을 애플리케이션 설계자에게 맡기고 아키텍처보다는 기능을 캡슐화하는 라이브러리를 제공하는 것이 훨씬 더 건설적입니다.
댓글
- Added to 즉, Microsoft에서 제공하는 MVVM (기본 제공, WPF)은 매우 부족합니다. 자신을 노련한 개발자라고 생각하는 프로그래머에게도 매우 실망 스럽습니다. 매직 문자열, 런타임의 모호한 예외, 라디오 버튼 그룹을 열거 형에 바인딩하는 것과 같은 대부분의 기본 사항은 다음과 같습니다. stackoverflow.com/q/397556/168719 -what 프레임 워크가 할 수 있습니까? 그들은이 수준의 복잡성을 반영하거나 그것에 대해 정말 두꺼운 추상화를 제공해야합니다.
- @KonradMorawski WPF 자체는 MVVM이 아닙니다. WPF로 코드를 작성할 수 있지만 ‘ MVVM이 아닙니다. 따라서 WPF 및 MVVM을 수행하려면 ‘ MVVM 프레임 워크를 사용하거나 직접 구현해야합니다.
- @Andy는 물론입니다. div id = “378c65288e”>
는 WPF가 MMVM을위한 의도 라고 말할 수 있습니다.저는 ‘ WPF에 기본 제공되는 MVVM 기능을 말합니다. 나는 당신이 여전히 뒤에서 코드를 할 수 있다는 것을 안다.
DataContext 등 답변
WPF에 대한 저의 첫 경험은 Caliburn을 사용하는 것입니다. Micro 그래서 이것은 아마도 대부분의 개발자와는 상당히 다를 것입니다. WPF와 Caliburn.Micro는 모두 WinForms에서 비롯된 매우 가파른 학습 곡선이라는 것을 알았지 만 둘 다 경험 한 후 한 쌍으로 사용하는 것이 즐거웠습니다. 현재 Caliburn.Micro가 사용되지 않는 다른 조직에서 일하고 있습니다. 중복 배관 코드가 많아서 코드베이스가 상당히 부풀어지고 불필요하게 복잡해집니다.
몇 가지 문제가 있다는 데 확실히 동의합니다. 디버깅을 복잡하게 만들 수있는 Caliburn.Micro를 사용하지만 일단 경험하면 다시 고통 스러울 가능성이 훨씬 적습니다. 향상된 개발 속도, 더 깔끔하고 간결한 코드, 더 나은 MVVM을 장려하는 전체 프레임 워크는 나에게 그만한 가치가 있습니다.
Caliburn.Micro는 또한 재고 WPF를 무효화하지 않습니다. 그 위에 빌드 할뿐입니다. 즉, 원하는 경우 WPF 기능을 계속 사용할 수 있고 원하는 경우 Caliburn을 사용할 수 있습니다. 이것은 TypeScript와 JavaScript가 내 마음에 공존하는 방식과 비슷합니다.
기회가 주어진다면 앞으로 작업 할 새로운 WPF 프로젝트에서 Caliburn.Micro를 가장 확실히 사용할 것입니다.
댓글
- 답변 해 주셔서 감사합니다. 2 년 후, 종속성 주입 컨테이너의 개념을 이해 한 후 이러한 프레임 워크를 ” 수락 “하는 것이 훨씬 쉬워졌습니다. 훌륭한 Mark Seeman ‘ s ” DI in .NET ” 책.
답변
Caliburn.Micro에 대한 불만으로 여기에 도착한 사람은 다음 프레임 워크를 살펴보십시오. Stylet
그것은 무슨 일이 일어나고 있는지에 대해 혼란스럽게 만드는 많은 마법을 제거한다는 점을 제외하면 Caliburn.Micro에서 영감을 얻었습니다. 또한 문서는 기술 전문 용어를 통하지 않고 훨씬 더 평이한 언어로 작성되었습니다. 초보자에게 훨씬 좋습니다.
또한 Stylet은 ViewModel-First 접근 방식을 사용합니다. Caliburn.Micro 및 기타 많은 프레임 워크는 일부 어색한 문제가있는 View-First 접근 방식을 사용합니다. 이미 SOLID 원칙과 패턴 화 된 코드에 능숙하다면 로직이 뷰가 아닌 시스템을 구동해야한다는 관점을 취하기 때문에 ViewModel-First 접근 방식이 더 자연 스러울 것입니다.
EventAggregator를 사용하고 메시징에는NotificationObject를 사용합니다. ViewModelBase 및 명령 용 MVVM Light ‘의RelayCommand. 중요한 것은 프레임 워크가 어떤 문제를 해결할 것인지 식별하고 해당 솔루션 만 사용하는 것입니다. ‘ ‘ 전체 프레임 워크 라이브러리를 사용해야한다고 생각하지 마세요.RelayCommand구현을 찾을 수 없었습니다 (” ” ICommand 속성에 바인딩하는 대신 규칙에 따라 메서드에 직접 바인딩합니다.RelayCommand.