나는 현재 WPF를 위해 MVVM을 내 머리로 가져 가려고합니다. 머리를 컨셉으로 돌리는 것이 아니라 멍청한 CRUD보다 구타를 벗어난 무언가를하는 실제 너트와 볼트 주위를 의미합니다.

내가 주목 한 것은 많은 프레임 워크와 대부분 / 모든 블로그 게시물이 '연령'에 있다는 것입니다.

이것이 낡은 모자이고 블로거가 Next Big Thing으로 옮겼 기 때문입니까, 아니면 그들이 말할 모든 것을 말했기 때문입니까?

다시 말해, 내가 여기서 놓친 것이 있습니까?

MVVM은 구식이 아니지만 처음부터 과장되었습니다. 나는 그것을 좋아하지 않았고 WinForms에 너무 오랫동안 머물렀다. 나무의 숲을 보지 못하고 목욕물로 아기를 내 쫓았습니다. 이제 WPF를 얻었고 코드를 마크 업과 혼합하고 싶지 않다는 아이디어를 얻었지만 마크 업을 한 곳에 고정하고 내 코드의 캐스트와 함께 참조 해제하는 Android 스타일을 선호합니다 (WPF에서도 가능) 어떤 이유로 든 유행하는 것은 결코 없었습니다).

그렇게하면보다 세밀한 제어가 가능하며 모든 "변경되지 않은"처리에 대해 걱정할 필요가 없습니다. "변경된"이벤트를 놓치면 테스트가 항상이를 잡아낼 수 없기 때문에 이것이 실제로 더 테스트 가능 하다고 생각합니다 .

요즘 추세 인 것처럼 보이는 약간의 "선언적"-상실 성을 잃게됩니다. . 그러나 MVVM을 사용하더라도 정신적 인 경우에만 작동합니다. 일부 위젯이 다른 위젯의 로그를 표시해야하는 경우 다른 핸들러와 다른 "변경된"이벤트를 작성해야하므로 "선언적"정의를 확장해야합니다.

2015 년 업데이트

WPF MVVM은 그 당시에 (r) 진화되었습니다. WPF와 마찬가지로. 그러나 둘 다 사마귀가있었습니다. 평범한 WPF에는 너무 많은 기능이 내장되어 있으며 (XML에 내장되어 있음) 다루기가 어려웠습니다. 실제로 WPF가 "프레임 워크"방식이 아닌 "라이브러리"방식을 취했다면 정말 멋진 기능으로 바뀌었을 수 있으며 전체 기술 세계가 완전히 다를 수 있습니다. MVVM 의 아이디어 는 훌륭했지만 MVVM을 WPF에 맞추려는 시도는 1) C #이 많은 상용구없이 실제로 표현할 수 없었고 2) 모달 팝업과 같은 WinForms 유물은 여전히 ​​이념적으로 널리 퍼져 있었지만 불가능했습니다. MVVM으로 쉽게 표현할 수 있습니다. 따라서 모든 것이 빨려 들었습니다.

즉, LOB 앱에 투명성 또는 GPU가 필요한 경우 여전히 Windows에서 유일한 현실적인 옵션입니다.

물론 React는 MVVM을 쓸모 없게 만들었습니다. VS2015에 네이티브 카운터가 없었기 때문에 실망했습니다. 현재 우리는 여전히 원시 WPF를 사용하고 있습니다 (괜찮지 만 오래된 느낌입니다 (실제로 winform 만큼 오래 된 느낌)). 또는이 시점에서도 있기 때문에, 아무것도 많은 오버 헤드 같은 느낌 - MVVM과 좋은 MVVM (각 1)의 단점을 노출하고있다.

WPF MVVM을 피할 것입니다. 그것은 여분의 층이며 아무도 더 이상 신경 쓰지 않습니다.

MVVM 프레임 워크로 수행 할 수있는 작업에는 한계가 있습니다.

Microsoft가 WPF를 출시 한 이후 WPF가 진행되지 않았기 때문에 "완료"되었습니다. 기술에 대한 업데이트가있는 경우 라이브러리도 업데이트해야합니다. 이것은 일어나지 않았습니다.