WPF MVVM w praktyce - bindingi, komendy i testowanie

Rozdzielenie interfejsu, logiki i danych potrafi uratować projekt WPF przed plątaniną zdarzeń, konwerterów i kodu w oknach. Zestawienie wpf mvvm sprowadza się do praktycznego wykorzystania wzorca Model-View-ViewModel, dzięki któremu aplikacja jest łatwiejsza do rozwijania, testowania i utrzymania. Pokażę, jak działają bindingi, komendy, powiadomienia o zmianach oraz gdzie kończą się korzyści tego podejścia.

Czym różnią się Model, View i ViewModel w WPF

MVVM dzieli aplikację na trzy części, z których każda ma inne zadanie. Ten podział nie jest sztuką dla sztuki. Przy większym programie sprawia, że zmiana wyglądu okna nie wymusza przepisywania logiki pobierania danych albo zapisu do bazy.

View to najczęściej plik XAML, na przykład MainWindow.xaml. Nie musi wiedzieć, skąd pochodzi lista klientów. Otrzymuje obiekt ViewModel jako DataContext i wiąże swoje kontrolki z jego właściwościami.

ViewModel jest pośrednikiem między interfejsem a resztą aplikacji. Udostępnia na przykład ObservableCollection, właściwość IsBusy oraz komendę SaveCommand. Dzięki temu widok opisuje przede wszystkim to, co ma pokazać, a nie jak wykonać całą operację.

Model nie musi być osobnym bytem dla każdej kontrolki. Może reprezentować encję z bazy, rekord konfiguracji albo wynik wywołania usługi. Ja staram się nie wkładać do niego kodu zależnego od WPF, ponieważ wtedy ten sam model można wykorzystać w testach, usłudze czy aplikacji webowej.

Jak wygląda przepływ danych

Użytkownik zmienia wartość w kontrolce, binding aktualizuje właściwość ViewModelu, a ViewModel może wywołać usługę lub zmienić stan ekranu. Gdy właściwość zgłosi zmianę przez INotifyPropertyChanged, WPF odświeży powiązane kontrolki.

W drugą stronę działa to podobnie. Gdy aplikacja pobierze dane i zmieni kolekcję albo właściwość, widok dostaje powiadomienie i pokazuje nowy stan. To właśnie automatyczna synchronizacja między XAML a obiektem ViewModelu jest największą praktyczną zaletą tego wzorca.

Binding i DataContext bez zgadywania, dlaczego nic się nie aktualizuje

Binding jest mechanizmem, który łączy właściwość kontrolki z właściwością obiektu. Najczęstszy problem początkujących nie wynika z samego MVVM, lecz z nieprawidłowego DataContext albo braku powiadomienia o zmianie.

Atrybut UpdateSourceTrigger=PropertyChanged powoduje aktualizowanie ViewModelu przy każdym wpisanym znaku. Bez niego kontrolka tekstowa często przekaże wartość dopiero po utracie fokusu, co jest poprawne, ale może zaskoczyć przy wyszukiwaniu na żywo.

Najprostsza właściwość musi poinformować WPF o zmianie. Można zrobić to ręcznie przez INotifyPropertyChanged, ale w nowych projektach wybieram zwykle bibliotekę CommunityToolkit.Mvvm, która usuwa powtarzalny kod.

using CommunityToolkit.Mvvm.ComponentModel;

public partial class MainViewModel : ObservableObject
{
    [ObservableProperty]
    private string searchText = string.Empty;

    [ObservableProperty]
    private string resultMessage = "Wpisz tekst";
}

Atrybut [ObservableProperty] generuje właściwość publiczną oraz kod powiadamiający o zmianie pola. To nie jest magia wykonywana w czasie działania programu, lecz generator kodu uruchamiany podczas kompilacji. Dzięki temu zachowujemy zwykłe właściwości .NET bez ręcznego pisania kilkunastu podobnych setterów.

Gdy binding milczy

Jeśli wartość nie pojawia się w widoku, sprawdzam kolejno DataContext, nazwę właściwości i Output w Visual Studio. WPF zapisuje tam komunikaty o nieudanych bindingach, a ich ignorowanie zwykle prowadzi do wielominutowego szukania problemu w złym miejscu.

• Nie ustawiaj lokalnego DataContext na kontenerze, jeśli przesłania ViewModel dziedziczony z okna.
• Upewnij się, że właściwość ma publiczny getter i setter, gdy binding ma działać w obie strony.
• Do dynamicznej listy używaj ObservableCollection, a nie zwykłej listy.
• Sprawdź typ danych, zwłaszcza przy konwersji tekstu na liczby, daty i wartości logiczne.

W przypadku list sama kolekcja też ma znaczenie. ObservableCollection informuje widok o dodaniu i usunięciu elementu, ale nie powiadamia automatycznie o zmianie właściwości pojedynczego elementu. Obiekt znajdujący się w kolekcji również powinien implementować INotifyPropertyChanged.

Komendy zastępują obsługę kliknięć w kodzie okna

W klasycznym podejściu zdarzenie Button.Click trafia do code-behind, a handler zaczyna pobierać wartości kontrolek i wykonywać operację. Przy kilku przyciskach jest to jeszcze znośne, lecz ekran szybko staje się trudny do testowania. ICommand pozwala opisać akcję jako właściwość ViewModelu.

Z CommunityToolkit.Mvvm można utworzyć komendę bez ręcznego implementowania interfejsu ICommand. Metoda oznaczona przez [RelayCommand] otrzyma wygenerowaną właściwość komendy.

using CommunityToolkit.Mvvm.Input;

public partial class MainViewModel : ObservableObject
{
    [ObservableProperty]
    private string searchText = string.Empty;

    [ObservableProperty]
    private bool isBusy;

    [RelayCommand]
    private async Task SearchAsync()
    {
        IsBusy = true;

        try
        {
            await Task.Delay(300);
            // Wywołanie serwisu i aktualizacja wyników
        }
        finally
        {
            IsBusy = false;
        }
    }
}

Dla metod asynchronicznych generator tworzy AsyncRelayCommand. To ważne, ponieważ operacja sieciowa albo dostęp do bazy nie powinny blokować wątku interfejsu. W prawdziwej aplikacji zamiast Task.Delay wywołuję serwis, a stan IsBusy wykorzystuję do zablokowania przycisku i pokazania postępu.

CanExecute i parametry

Komenda może decydować, czy akcja jest dostępna. Na przykład zapis nie powinien być możliwy, gdy formularz jest pusty albo trwa już poprzednia operacja. W prostych ekranach wystarczy wygenerowanie warunku przez atrybut.

[RelayCommand(CanExecute = nameof(CanSearch))]
private async Task SearchAsync()
{
    await LoadResultsAsync();
}

private bool CanSearch()
{
    return !IsBusy && !string.IsNullOrWhiteSpace(SearchText);
}

Po zmianie SearchText lub IsBusy trzeba odświeżyć stan komendy, jeśli framework nie zrobi tego w danym scenariuszu automatycznie. W praktyce dobrze jest doprowadzić do tego, aby przycisk był nieaktywny z jasnego powodu, zamiast pozwalać użytkownikowi kliknąć akcję, która zakończy się wyjątkiem.

Nie próbuję jednak przerabiać każdej interakcji na komendę. Animacja, ustawienie fokusu czy czysto wizualna reakcja kontrolki mogą pozostać w code-behind albo być obsłużone przez behavior. MVVM ma ograniczać zależności, a nie wymuszać sztuczną architekturę.

Jak zbudować mały ekran WPF zgodnie z tym podejściem

Najlepiej uczyć się na małym, kompletnym przepływie. Załóżmy ekran wyszukiwania produktów. ViewModel przechowuje tekst zapytania, wyniki i stan ładowania, a osobny serwis odpowiada za pobieranie danych.

1. Wydziel serwis

public interface IProductService
{
    Task

Interfejs pozwala podmienić prawdziwe API atrapą podczas testów. To drobna decyzja, która po kilku miesiącach oszczędza sporo pracy, bo ViewModel nie jest wtedy przyspawany do konkretnego klienta HTTP albo bazy danych.

2. Umieść logikę ekranu w ViewModelu

public partial class ProductsViewModel : ObservableObject
{
    private readonly IProductService service;

    [ObservableProperty]
    private string phrase = string.Empty;

    [ObservableProperty]
    private IReadOnlyList products =
        Array.Empty();

    [ObservableProperty]
    private bool isBusy;

    public ProductsViewModel(IProductService service)
    {
        this.service = service;
    }

    [RelayCommand(CanExecute = nameof(CanSearch))]
    private async Task SearchAsync(CancellationToken token)
    {
        IsBusy = true;

        try
        {
            Products = await service.SearchAsync(Phrase, token);
        }
        finally
        {
            IsBusy = false;
        }
    }

    private bool CanSearch() =>
        !IsBusy && !string.IsNullOrWhiteSpace(Phrase);
}

ViewModel nie wie, czy wyniki zostaną pokazane w tabeli, liście czy kafelkach. Wie tylko, że udostępnia dane i reaguje na akcję wyszukiwania. Taka separacja daje mi swobodę przebudowania XAML bez naruszania logiki.

3. Zwiąż dane z XAML

W tym przykładzie nie ma odwołania do nazwy kontrolki ani ręcznego przypisywania ItemsSource. Widok deklaruje zależności, a ViewModel zarządza stanem. Przy rozbudowie ekranu można dodać komunikat błędu, pasek postępu albo paginację bez zmiany podstawowego modelu działania.

Testy, skalowanie i ograniczenia wzorca MVVM

Największy zysk z MVVM pojawia się wtedy, gdy ViewModel ma logikę, którą rzeczywiście można sprawdzić bez uruchamiania okna. Test powinien móc utworzyć ViewModel z atrapą serwisu, wywołać komendę i zweryfikować wynik oraz stan IsBusy.

[Fact]
public async Task Search_updates_products()
{
    var service = new FakeProductService();
    var viewModel = new ProductsViewModel(service);

    viewModel.Phrase = "klawiatura";
    await viewModel.SearchCommand.ExecuteAsync(null);

    Assert.NotEmpty(viewModel.Products);
}

W większym projekcie dokładam wstrzykiwanie zależności, osobne serwisy aplikacyjne i modele odpowiedzi. Nie tworzę jednak od razu dziesięciu warstw. Prosta aplikacja nie potrzebuje korporacyjnej architektury, a nadmiar abstrakcji potrafi utrudnić start bardziej niż code-behind.

Przeczytaj również: Windows SDK - co zawiera i jak dobrać wersję do projektu?

Błędy, które wracają najczęściej

• ViewModel wykonuje operacje synchroniczne na wątku UI, przez co okno przestaje odpowiadać.
• Cała logika trafia do jednego ogromnego ViewModelu zamiast zostać przeniesiona do serwisów.
• Autor walczy z każdym eventem, choć niektóre zdarzenia dotyczą wyłącznie prezentacji.
• Komunikaty błędów są połykane albo zastępowane ogólnym „Wystąpił błąd”.
• Brakuje anulowania długich operacji, więc starsze wyszukiwanie może nadpisać nowszy wynik.
• Widok i ViewModel są łączone przez ręczne wyszukiwanie kontrolek, co odbiera sens bindingom.

MVVM nie rozwiązuje automatycznie problemu okien dialogowych, nawigacji ani powiadomień systemowych. Do tych elementów można użyć usług interfejsu, behaviorów lub mechanizmu komunikatów, ale trzeba uważać, aby nie ukryć całej logiki za globalnym „messengerem”. Ja preferuję jawne zależności i komunikację ograniczoną do konkretnego scenariusza.

Warto też pamiętać o wydajności. Bindingi są wygodne, lecz tysiące ciężkich konwerterów, niepotrzebne odświeżanie kolekcji i ładowanie dużych zbiorów naraz nadal spowolnią aplikację. W takim przypadku pomaga wirtualizacja, paginacja, anulowanie żądań oraz aktualizowanie interfejsu partiami.

Najmniejszy sensowny standard dla nowego projektu WPF

Na początku wystarczy kilka zasad. Każdy ekran powinien mieć jasno określony ViewModel, operacje biznesowe powinny trafiać do serwisów, a komunikacja z XAML powinna odbywać się przez właściwości i komendy. Do powiadomień dobrze wykorzystać ObservableObject, a do akcji RelayCommand lub AsyncRelayCommand.

Nie traktuję MVVM jako religijnego zakazu używania code-behind. Traktuję je jako sposób na utrzymanie granicy między wyglądem a działaniem aplikacji. Jeśli po kilku miesiącach mogę zmienić układ okna, przetestować wyszukiwanie bez uruchamiania WPF i szybko znaleźć miejsce odpowiedzialne za błąd, wzorzec spełnił swoje zadanie.