WPF MVVM Używanie poleceń a obsługa zdarzeń

Question

Podoba mi się wzór MVVM, gdy zaczniesz go używać, uzależnisz się od niego.

Wiem, że w idealnym świecie Twój kod View jest prawie pusty (może jakiś kod w konstruktorze) i każdy aspekt widoku jest manipulowany z ViewModel.

Ale zdarzają się sytuacje, w których tworzenie nowych pól, właściwości, poleceń w ViewModel tworzy więcej kodu niż implementacja tej samej rzeczy w procedurze obsługi zdarzeń.

Na chwilę trzymać się następującej zasady:

Jeśli kod obsługi zdarzenia manipuluje bardzo mała część jego widok (dla obsługi zdarzenia kliknięcia przykład przycisku zwiększa czcionka niektórych TextBlock, że znajduje się on w tym samym widzenia) to jest to OK, aby implementacja logiki wewnątrz procedur obsługi zdarzeń. Ale jeśli View musi manipulować logiką biznesową lub uzyskiwać dostęp do zasobów, które są poza zasięgiem widoku, przypisuję te obowiązki do ViewModel.

Co sądzisz o moim podejściu?

Czego próbujesz uniknąć, używając programów obsługi zdarzeń i ViewModel?

Jakie najlepsze praktyki można polecić podczas korzystania z wzoru MVVM?

Answer 1

Powiedziałbym, że twoja zasada kciuka nie jest zła.

Moim zdaniem główną troską jest "czy jest to specyficzne dla kodu, czy też odnosi się do logiki biznesowej?".

To jest w porządku mieć kod w widoku, jeśli ten kod jest ściśle tutaj, aby zmodyfikować widok i nie prowadzić jakiejkolwiek logiki biznesowej. Twój przykład zmiany rozmiaru czcionki jest doskonałym przykładem kodu, który jest idealnie czysty w widoku (i zwiększyłby hałas w ViewModelu, co utrudnia zrozumienie i utrzymanie). W zasadzie już to robisz, jeśli używasz wyzwalaczy, więc to nie jest takie dziwne.

Należy jednak pamiętać, że w przypadku testów jednostkowych bardzo trudno będzie przetestować ten układ logiki widoku. Jeśli potrzebujesz go przetestować, może lepiej byłoby umieścić go w viewmodelu.

Answer 2

myślę, że może dodać coś do poprzedniego komentarza, jak również,

Zamiast obsługi zdarzeń, z bardzo skromnej Experience Komendy dają mi dużo większą elastyczność w tym sensie, że stanowi niezależny mechanizm reagowania na zdarzenia/akcje z różnych kontrolek z możliwością sprawdzenia statusu samego polecenia.