MVVM w .NET - jak oddzielić UI od logiki aplikacji?

Gdy ekran aplikacji zaczyna obsługiwać ładowanie danych, walidację, komunikaty błędów i kilka akcji użytkownika, kod-behind szybko przestaje być wygodnym miejscem na całą logikę. Architektura MVVM porządkuje ten problem, oddzielając interfejs od stanu i operacji aplikacji. Pokażę, jak działają Model, View i ViewModel, jak połączyć je w aplikacji .NET oraz kiedy ten wzorzec rzeczywiście pomaga.

Na czym polega podział Model View ViewModel

MVVM, czyli Model-View-ViewModel, to wzorzec architektoniczny dla aplikacji z interfejsem użytkownika. Jego główna idea jest prosta: ekran nie powinien zawierać całej logiki biznesowej. Zamiast tego View prezentuje stan, ViewModel przygotowuje dane dla ekranu, a Model zajmuje się domeną i dostępem do danych.

W praktyce użytkownik naciska przycisk w View, ale sama akcja jest obsługiwana przez komendę ViewModelu. ViewModel wywołuje serwis, aktualizuje swój stan, a binding przekazuje zmianę do interfejsu. Dzięki temu kod odpowiedzialny za działanie aplikacji nie jest przyklejony do konkretnego przycisku, strony ani frameworka UI.

Najważniejsza granica przebiega między View i ViewModelem. ViewModel nie powinien wiedzieć, czy działa z XAML-em, oknem desktopowym czy ekranem mobilnym. Jeżeli w jego kodzie pojawia się `Button`, `ContentPage` albo odwołanie do konkretnej kontrolki, zwykle oznacza to, że część odpowiedzialności trafiła w złe miejsce.

Model nie zawsze oznacza encję z bazy

Model może być encją domenową, rekordem zwróconym przez API albo obiektem opisującym wartość, na przykład adres lub kwotę. Nie musi jednak odwzorowywać jeden do jednego tabeli w bazie danych. Często lepiej, gdy ViewModel korzysta z osobnych modeli prezentacyjnych, zamiast wystawiać bezpośrednio obiekty infrastruktury.

ViewModel to stan konkretnego ekranu

Dobry ViewModel odpowiada na pytanie, co ekran ma pokazać i co użytkownik może teraz zrobić. Może przechowywać listę produktów, informację o ładowaniu, komunikat błędu oraz komendę odświeżenia. Nie powinien natomiast stawać się magazynem całej aplikacji ani zastępować warstwy domenowej.

Jak przepływ danych działa w aplikacji .NET

W aplikacjach WPF, WinUI i .NET MAUI połączenie między View a ViewModelem zapewnia data binding. Kontrolka obserwuje właściwość ViewModelu, a zmiana wartości powoduje aktualizację interfejsu. W drugą stronę działa to podobnie, na przykład wpisanie tekstu do pola może zmienić właściwość ViewModelu.

Żeby interfejs wiedział o zmianie, ViewModel musi zgłosić powiadomienie. Najczęściej służy do tego INotifyPropertyChanged albo gotowe klasy z pakietu CommunityToolkit.Mvvm. W przypadku kolekcji używa się zwykle ObservableCollection, która informuje widok o dodaniu i usunięciu elementów.

public partial class ProductsViewModel : ObservableObject
{
    [ObservableProperty]
    private bool isBusy;

    [ObservableProperty]
    private string? errorMessage;

    public ObservableCollection Products { get; } = new();

    private readonly IProductService service;

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

    [RelayCommand]
    private async Task LoadAsync()
    {
        if (IsBusy)
            return;

        try
        {
            IsBusy = true;
            ErrorMessage = null;

            var products = await service.GetAsync();

            Products.Clear();

            foreach (var product in products)
                Products.Add(product);
        }
        catch (Exception)
        {
            ErrorMessage = "Nie udało się pobrać produktów.";
        }
        finally
        {
            IsBusy = false;
        }
    }
}

Atrybuty z przykładu generują właściwości i komendę podczas kompilacji. To ogranicza ilość powtarzalnego kodu, ale nie zmienia zasad wzorca. Nadal trzeba pilnować, aby operacje I/O były asynchroniczne, a interfejs nie był blokowany podczas komunikacji z API lub bazą danych.

W widoku komenda i właściwości mogą wyglądać tak:

Istotny jest także BindingContext, czyli obiekt, z którego widok pobiera wartości. Jeżeli binding nie działa, pierwsze miejsce do sprawdzenia to właśnie kontekst widoku, nazwa właściwości oraz informacja o zmianach. W praktyce wiele problemów z MVVM nie wynika z samego wzorca, tylko z literówki w bindingu albo z ustawienia kontekstu na niewłaściwym obiekcie.

Jak zbudować ekran w stylu MVVM

Najbezpieczniej zaczynać od stanu ekranu, a nie od kontrolek. Najpierw zapisuję, jakie dane mają się pojawić, jakie operacje może wykonać użytkownik i jakie sytuacje trzeba pokazać. Dopiero później tworzę XAML, który ten stan prezentuje.

1. Zdefiniuj model, na przykład `Product`, `Order` albo `Customer`.
2. Wydziel serwis odpowiedzialny za API, bazę danych lub pliki.
3. Utwórz ViewModel z właściwościami, komendami oraz stanami ładowania i błędu.
4. Podłącz zależności przez konstruktor, najlepiej korzystając z wbudowanego kontenera DI.
5. Zbuduj View wyłącznie wokół bindingów i komend.
6. Dodaj testy ViewModelu, zanim ekran rozrośnie się o kolejne scenariusze.

Załóżmy, że ekran ma wyświetlić listę zamówień. Model opisuje pojedyncze zamówienie, serwis pobiera kolekcję, a ViewModel dodaje informacje potrzebne tylko dla UI, takie jak `IsRefreshing`, `IsEmpty` czy `ErrorMessage`. To właśnie ViewModel tłumaczy dane domenowe na język ekranu.

Nie polecam umieszczania wywołania HTTP bezpośrednio w metodzie komendy, jeśli aplikacja ma więcej niż jeden ekran. Lepiej wstrzyknąć interfejs serwisu, ponieważ wtedy ViewModel można testować z atrapą danych, bez prawdziwego API i bez zależności od sieci.

public interface IOrderService
{
    Task

W .NET MAUI rejestracja zależności może znajdować się w konfiguracji aplikacji. Dzięki temu ViewModel nie tworzy sam serwisu przez new i nie musi znać sposobu jego konfiguracji. To drobna decyzja, która mocno ułatwia późniejsze testowanie oraz wymianę implementacji.

Kiedy MVVM ma sens, a kiedy jest przesadą

MVVM szczególnie dobrze pasuje do aplikacji, w których ekran ma własny stan, reaguje na wiele zdarzeń i pobiera dane z kilku źródeł. Dotyczy to paneli administracyjnych, aplikacji biznesowych, aplikacji mobilnych oraz rozbudowanych programów desktopowych.

Nie każdy fragment kodu musi być na siłę „czystym MVVM”. Animacja, fokus kontrolki czy nietypowe zachowanie wizualne mogą pozostać w code-behind. Microsoft również wskazuje, że View może zawierać niewielką ilość logiki czysto wizualnej. Problemem nie jest obecność code-behind, tylko umieszczanie w nim logiki biznesowej.

Trzeba też odróżnić MVVM od MVC. MVC często organizuje aplikację wokół żądania i odpowiedzi HTTP, natomiast MVVM koncentruje się na synchronizacji stanu interfejsu z ViewModelem. Te wzorce mogą współistnieć, ale rozwiązują różne problemy.

Najczęstsze błędy w implementacji

Jeden ViewModel dla całej aplikacji

Na początku kuszące jest stworzenie klasy `MainViewModel`, która obsługuje wszystkie ekrany. Po kilku tygodniach trafiają do niej użytkownicy, zamówienia, ustawienia i nawigacja. Efekt to klasa trudna do testowania i jeszcze trudniejsza do zmiany. Lepiej, aby każdy większy ekran miał własny ViewModel, a wspólne operacje trafiały do serwisów.

Logika biznesowa w View

Warunek zapisany w code-behind może wyglądać niewinnie, ale szybko zaczyna być kopiowany w kilku miejscach. Jeżeli decyzja wpływa na wynik biznesowy, przenieś ją do Modelu lub serwisu. View powinien przede wszystkim opisywać, jak coś wygląda i na co jest zbindowane.

ViewModel sterujący kontrolkami

Odwołania do Entry, Label czy Navigation wiążą ViewModel z konkretnym frameworkiem. Zamiast tego wystaw właściwość `IsBusy`, komendę `SaveCommand` albo komunikat `ErrorMessage`. Stan powinien przepływać do widoku, a nie być ręcznie ustawiany na kontrolkach z poziomu ViewModelu.

Brak stanów pośrednich

Ekran, który zna tylko stan „dane są” albo „danych nie ma”, będzie źle zachowywał się podczas wolnego połączenia. Zwykle potrzebujesz co najmniej stanów `Loading`, `Loaded`, `Empty` i `Error`. Nie zawsze muszą być osobnym enumem, ale użytkownik powinien dostać jasną informację, co aktualnie dzieje się z aplikacją.

Synchroniczne operacje na wątku UI

Wywołanie sieci, odczyt dużego pliku lub ciężkie zapytanie wykonane synchronicznie zamrozi interfejs. W ViewModelach używaj `Task`, `await` i anulowania operacji tam, gdzie ma to sens. Sama obecność metody oznaczonej jako `async` nie wystarczy, jeśli w środku nadal wykonujesz kosztowną pracę blokującą.

Przeczytaj również: Pętla do-while w C# - składnia, przykłady i pułapki

Nadmierna liczba abstrakcji

MVVM nie wymaga tworzenia interfejsu dla każdej właściwości ani osobnej fabryki dla każdej komendy. Abstrakcje powinny rozwiązywać konkretny problem, na przykład ułatwiać testowanie serwisu albo wymianę źródła danych. Prosty ViewModel jest lepszy niż architektura pełna pustych warstw.

Jak testować ViewModel bez uruchamiania interfejsu

Jedną z największych zalet tego wzorca jest możliwość testowania zachowania ekranu jako zwykłego kodu C#. Test nie musi otwierać aplikacji, klikać przycisku ani czekać na renderowanie XAML. Wystarczy podać ViewModelowi atrapę serwisu, wywołać komendę i sprawdzić wynik.

Przykładowy test powinien odpowiedzieć na konkretne pytania. Czy po załadowaniu danych kolekcja zawiera oczekiwane elementy? Czy podczas pobierania `IsBusy` ma wartość `true`? Czy błąd z serwisu zmienia komunikat dla użytkownika? Czy ponowne uruchomienie komendy nie rozpoczyna kilku identycznych operacji?

[Fact]
public async Task LoadCommand_adds_products_to_collection()
{
    var service = new FakeProductService(
        new Product("Klawiatura", 299m));

    var viewModel = new ProductsViewModel(service);

    await viewModel.LoadCommand.ExecuteAsync(null);

    Assert.Single(viewModel.Products);
    Assert.Equal("Klawiatura", viewModel.Products[0].Name);
    Assert.False(viewModel.IsBusy);
}

Nie trzeba testować frameworka bindingów w każdym teście ViewModelu. Wystarczy zweryfikować, czy właściwości i komendy zmieniają się zgodnie z oczekiwaniami. Bindingi oraz konfigurację widoku można sprawdzać osobno, na przykład podczas testów integracyjnych lub ręcznej weryfikacji konkretnego ekranu.

Dobrym sygnałem jakości jest sytuacja, w której ViewModel można utworzyć w teście, przekazując mu tylko kilka zależności. Jeśli potrzebuje całej aplikacji, kontenera DI i dostępu do kontrolek, prawdopodobnie ma zbyt szeroki zakres odpowiedzialności.

Jak rozpoznać dobrą granicę MVVM w projekcie

Najprostszy test polega na wyobrażeniu sobie wymiany interfejsu. Jeśli ten sam stan i reguły można wykorzystać w innym widoku bez przepisywania logiki, granica między warstwami jest prawdopodobnie sensowna. Jeśli zmiana koloru przycisku wymaga edycji serwisu pobierającego dane, zależności są już zbyt ciasne.

• View opisuje wygląd i zachowania czysto wizualne.
• ViewModel opisuje stan ekranu oraz akcje dostępne dla użytkownika.
• Serwisy obsługują komunikację z API, bazą danych i plikami.
• Model nie zna kontrolek ani cyklu życia widoku.
• Każdy ekran ma jasno określony zakres odpowiedzialności.
• Operacje asynchroniczne nie blokują interfejsu.
• Najważniejsze scenariusze można sprawdzić w testach jednostkowych.

W mojej ocenie MVVM działa najlepiej wtedy, gdy traktuje się go jako narzędzie do kontroli zależności, a nie obowiązkowy zestaw klas. Jeśli ekran jest mały, prosty code-behind może być rozsądny. Gdy pojawiają się dane z API, walidacja, kilka stanów i rozbudowane akcje, dobrze zaprojektowany ViewModel szybko zaczyna się zwracać.

Najważniejsze jest zachowanie zdrowego podziału. View ma prezentować, Model ma reprezentować domenę, a ViewModel ma pośredniczyć między nimi w sposób zrozumiały i testowalny. Taka struktura nie usuwa całej złożoności aplikacji, ale sprawia, że wiadomo, gdzie szukać problemu i gdzie wprowadzić kolejną zmianę.