주어진 MVVM 응용 프로그램에서 프레임 워크 (Caliburn.Micro 등)를 사용하지 않도록 선택하는 방법은 무엇입니까?

한 번은 MVVM / WPF 프로젝트를 시작했는데,이 프로젝트는 결국 구축 및 배포되었으며 많은 Caliburn.Micro MVVM 프레임 워크를 연구했습니다. 사실 : 나는 Caliburn.Micro를 사용 하지 않고 결국 MVVM 개념 (특히 ViewModelBaseand RoutedCommand클래스 만)을 구현하게되었습니다.

이제는 "단일 사용자 리치 클라이언트 오프라인 데스크톱 응용 프로그램"과 같은 줄을 따라 다소 큰 프로젝트에 할당되었고 Caliburn.Micro를 사용하기로 결정했습니다. 그리고 그것이 나의 "문제"가 시작되는 곳입니다.

이 유명한 블로그 게시물 에서 "MVVM을 사용 하는 경우 프레임 워크 가 필요 합니다"라는 제목 을 읽었습니다 .

"프레임 워크없이 MVVM과 같은 것을 시도하는 것은 엄청난 양의 작업입니다. 수많은 중복 된 코드, 바퀴를 재발 명하고 사람들이 다르게 생각하도록 재교육 합니다.

최소한 프레임 워크를 사용하면 중복 코드를 피하고 바퀴를 재발 명 할 필요가 없으므로 사람들을 재교육하는 데 집중할 수 있습니다. 재 훈련 부분은 일반적으로 피할 수 없지만 프레임 워크는 배관 코드와 구조를 제공하여 프로세스를 더 쉽게 만듭니다. "

처음 읽을 때는 동의하지만 실제 응용 프로그램 에서 Caliburn.Micro (CM)에 대한 실제 경험은 실마리 가없고 혼란 스럽습니다. 즉, 프레임 워크는 프로세스를 전혀 쉽게 만들지 못 했으므로 그 반대입니다. 오히려 (너무) 비공식 문서에 롭 아이젠 버그에 의해 제공 끊임없이 반복 예 읽기 및 제공 뒤얽힌 샘플에서 추론의 사용 패턴에 노력하고, 사물이 작동하도록 설계 할 것 같다 그들의 완전히 간접 클래스 및 인터페이스 관계를 기반 에 당신이 노련한 천재가 아니라면 부작용은 인간적으로 불가능 해 보입니다.

위의 사소한 시나리오는 내가 다루지 않은 IoC 컨테이너와 관련이 있고 내가 가지고 있지 않은 문제 를 해결하는 것처럼 보입니다 . 내 문제와 응용 분야에 대해 생각하는 대신 이러한 것들을 배우는 데 더 많은 프로젝트 시간을 보내고 싶지 않습니다. 방금 바나나를 원했지만 CM은 바나나 바구니를 들고있는 고릴라 (IoC)를주었습니다.

이제 실제로 구현하려는 소수의 MVVM 관련 클래스로만 구성된 자체 제작 MVVM 프레임 워크로 돌아 가려고합니다. 여기서 뭔가를 잃을 경우를 대비하여 CM에 기회를 주려고합니다. 단지 경험과 무지에서 "잘못된 길"을 분명히하는 것입니다. 따라서 질문은 다음과 같습니다.

"프레임 워크가 일을 더 쉽고 자연스럽게 만든다"는 광범위한 합의가 있지만, 그 반대의 경우가 발생하면 프레임 워크를 사용해서는 안되거나 틀린 방법을 배우려고한다는 의미입니까? 처음에 프레임 워크를 사용해서는 안되는 단서가 있습니까? 아니면 간단한 MVVM 개발을 위해 CM을 사용하는 방법을 알아내는 "올바른"방법이 있습니까?

CaliburnMicro와 MVVMLight를 사용해 보았고 Caliburn을 사용할 때 실제로 느끼는 느낌이들 것입니다. 오래된 Text = "{Bind PropertyName}"대신 Name = "PropertyName"을 사용하여 컨트롤을 속성에 바인딩 할 수 있다는 것이 정말 마법 같은 느낌입니다. end Caliburn은이 마법적인 일을하기 위해 배 밖으로 나아갑니다. 무언가 잘못되면 정말 디버깅하기가 어렵고, 일을 더 악화시키기 위해 한 가지 일을 할 수있는 방법이 많이 있습니다.

그러나 MVVMLight를 사용하면 얇고, 사용하면 MVVM 프레임 워크와 거의 100 % 비슷하며 일부 기능이 뿌려져있을 수 있습니다.

나는 이것이 "프레임 워크를 사용하지 않는 방법"에 대한 귀하의 질문에 대답하지는 않지만 솔직히 그 길을 잘못 가고 있기 때문에 그 길로 갈 것을 권할 수는 없습니다. 하나 먼저.

MVVM이 무엇인지 인식하는 것이 중요합니다. 재 구현할 필요가없는 일부 공유 기능 (JPEG 파일 구문 분석 또는 지정된 SQL 데이터베이스 서버에 연결)이 아니라 패턴 입니다. 즉, 풍부한 GUI 구현 방법을 선택할 수있는 패턴입니다. 따라서 패턴의 구현이 간단하고 간단하다면 프레임 워크가 아니라 패턴을 사용하는 데 부끄러움이 필요하다고 생각하지 않습니다.

실제로, 프레임 워크로서의 전체 패턴 아이디어가 너무 멀리 나아 갔다고 생각합니다. 패턴이 되려면 솔루션 클래스의 일반적인 형태 여야합니다. 이것이 그렇기 때문에 패턴을 사용하는 시스템에 맞게 패턴을 조정해야하며, 모든 크기에 맞는 패턴을 사용하려고하면 그렇게 할 수 없습니다. 패턴 구현을 애플리케이션 디자이너에게 맡기고 아키텍처보다는 기능을 캡슐화하는 라이브러리를 제공하는 것이 훨씬 더 건설적입니다.

WPF에 대한 나의 첫 경험은 Caliburn.Micro를 사용했기 때문에 이것은 아마도 대부분의 개발자와는 상당히 다릅니다. WPF와 Caliburn.Micro는 WinForms에서 오는 가파른 학습 곡선이라는 것을 알았습니다. 그러나 둘 다에 대한 경험이 있으면 쌍으로 사용하는 즐거움을 발견했습니다. 현재 Caliburn.Micro를 사용하지 않는 다른 조직에서 일하고 있는데 코드베이스가 부풀어지고 불필요하게 복잡 해지는 중복 배관 코드가 많이 있습니다.

Caliburn.Micro에는 디버깅이 복잡 할 수 있지만 문제가 발생하면 다시는 고통을 덜 겪을 가능성이 있다는 데 동의합니다. 향상된 개발 속도, 더 깨끗하고 깔끔한 코드와 더 나은 MVVM을 장려하는 전체 프레임 워크는 나에게 가치가 있습니다.

Caliburn.Micro는 또한 재고 WPF를 무효화하지 않으며, 그 위에 빌드되기 때문에 원하는 경우 WPF 기능을 계속 사용할 수 있으며 Caliburn을 원하는 경우 몇 비트 및 조각으로 사용할 수 있습니다. 이것은 TypeScript와 JavaScript가 서로 공존하는 방식과 비슷합니다.

기회가 주어진다면 향후 작업 할 새 WPF 프로젝트에서 Caliburn.Micro를 가장 확실히 사용할 것입니다.

Caliburn.Micro를 사용하여 좌절감을 느끼는 사람은 다음 프레임 워크를 살펴보십시오. Stylet

Caliburn.Micro에서 영감을 얻었습니다. 일어나는 일에 대해 혼란스러워하는 많은 마법을 제거합니다. 또한 설명서는 기술 전문 용어를 사용한다고 가정하지 않고 훨씬 더 평범한 언어로 작성되었습니다. 초보자에게는 훨씬 좋습니다.

또한 Stylet은 ViewModel-First 접근 방식을 취합니다. Caliburn.Micro와 다른 많은 프레임 워크는 View-First 접근 방식을 취하는데, 이는 다소 어색한 문제가 있습니다. SOLID 원칙과 패턴 코드를 이미 잘 알고 있다면 ViewModel-First 방식이 더 자연 스러울 것입니다. 뷰 모델이 아닌 로직이 시스템을 구동해야한다는 관점을 취하기 때문입니다.