Dlaczego zdarzenia i polecenia w MVVM są tak niewspierane przez WPF/Visual Studio?

Question

Podczas tworzenia aplikacji WPF z wzorcem MVVM, wydaje się, że muszę samodzielnie zebrać niezbędne narzędzia, aby rozpocząć nawet najbardziej podstawową obsługę zdarzeń, np.

• AttachedBehaviors dostaję od here
• DelegateCommands dostaję od here

Teraz szukam jakiś sposób obsłużyć zdarzenia ItemSelected w ComboBox i otrzymuję propozycje sztuczek i obejść, aby to zrobić (przy użyciu wyzwalacza XAML lub mieć inne elementy powiązane z wybranym elementem itp.). Ok, mogę zejść tą drogą, ale wydaje się, że wymyśliłem koło. Byłoby miło po prostu wybrać polecenie ItemSelected, które mogę obsłużyć w moim ViewModelu.

jestem brakuje jakiś zestaw standardowych narzędzi czy każdy robi MVVM z WPF zasadzie budowania i łącząc swój własny zestaw narzędzi tak, aby mogli wykonać najprostszych zadań instalacyjnych ze zdarzeń i poleceń, rzeczy, które mają tylko kilka linii w kodzie z tyłu za pomocą Click = "eventHandler"?

Answer 1

Według Josh Smith article o MVVM, został zaprezentowany światu w październiku 2005 roku na John Gossman's blog.

Odtąd powiedziałbym, że WPF/MVVM zajęło kolejne 2-3 lata, aby naprawdę wystartować i zostać zaakceptowanym przez społeczność, wtedy było już za późno na modernizację WPF w celu wsparcia problemów z MVVM. Też powiedziałbym, że WPF stworzył MVVM, więc wydaje się, że wstecz mieć zmianę WPF do obsługi MVVM.

Wreszcie, nie każdy robi WPF używa MVVM, więc API musi obsługiwać standard wykorzystanie zdarzeń itp

Tak więc, aby odpowiedzieć na to pytanie, tak każdy jest obecnie wprowadzenie swój własny zestaw narzędzi razem jako " oficjalne "wsparcie zapewnia tylko ramy DelegateCommands w tym momencie.

Answer 2

Zobacz ten szablon projektu MVVM dla VisualStudio.

http://blogs.msdn.com/llobo/archive/2009/05/01/download-m-v-vm-project-template-toolkit.aspx

Z tego szablonu można uzyskać różne klasy DelegateCommand które obejmują różne potrzeby ICommands i klasy CommandReference który pomaga z kluczowych wiązań.

To dobry początek ...

Answer 3

Becuase MVVM został "wynaleziony" sposób po WPF ... stąd dlaczego duże kawałki układanki MVVM nie są częścią struktury WPF.

Nie tylko to, ale sama MVVM została uznana za "wzór", zanim jeszcze została udowodniona/praktykowana w prawdziwym świecie. To kompletne przeciwieństwo tego, o co chodzi w szablonach - zazwyczaj są one wykrywane i dokumentowane po wielu latach udanego użytkowania przez wiele różnych osób.

Jeden facet wymyślający wzór nie tworzy wzoru.

Answer 4

Masz rację co do złożoności poleceń.Staram się podążać za wzorcem M-V-VM tak blisko, jak to tylko możliwe, ale nie mogę usprawiedliwić wyrafinowanych obejść, aby poradzić sobie z prostym zdarzeniem użytkownika.

Moim zdaniem można obsłużyć zdarzenie użytkownika w widoku, co znacznie upraszcza kod. Jeśli poradzisz sobie z zdarzeniem użytkownika w widoku, twój kod dostępu do widoku powinien natychmiast wywołać metodę na ViewModel. W ten sposób nadal zachowujesz swoją logikę w ViewModelu ... po prostu masz mały kod instalacyjny (event handler) w widoku. Wiem, że purystom M-V-VM wydaje się, że nie powinno być żadnego kodu w kodzie Viewa z tyłu, ale czasami bardziej sensowne jest zezwolenie na prosty kod na płycie, jak na przykład program do obsługi zdarzeń. Pamiętaj, że inni mogą czytać/modyfikować twój kod w przyszłości i dużo łatwiej jest zrozumieć obsługę zdarzeń niż DelegateCommand.

Answer 5

Miło mi słyszeć, że nie jestem jedynym, który myśli, że dowodzące implementacje są przesada. Databinding wydaje się naturalnie dobrze obsługiwany, ale od tygodni walczę z głową, próbując zrozumieć powiązania poleceń dla rzeczy innych niż przyciski i elementy, które z niego odziedziczą.

Dziękujemy za zamieszczenie tego pytania. Myślę, że od teraz będę obsługiwać wszystkie zdarzenia w warstwie widoku z przekierowaniem do funkcji modelu widoku. Myślę, że w ten sposób nauczyli podstawowych MVVM w jednym z 2 X dni kursu Microsoft XAMLFest. Wystarczająco dobrze dla mnie!