WPF w C# - jak zacząć i kiedy wybrać WinUI?

Gdy aplikacja ma działać wyłącznie w systemie Windows, a jednocześnie oferować rozbudowany interfejs, obsługę danych i wygodną pracę z klawiaturą oraz myszą, połączenie C# i WPF nadal jest bardzo mocnym wyborem. W tym artykule pokazuję, jak działa Windows Presentation Foundation, od czego zacząć projekt, kiedy stosować XAML i MVVM oraz w jakich sytuacjach lepiej rozważyć WinForms albo WinUI.

Czym jest WPF i do czego służy

WPF, czyli Windows Presentation Foundation, to framework .NET do budowania graficznych aplikacji desktopowych dla systemu Windows. Interfejs tworzy się najczęściej w języku XAML, natomiast zachowanie aplikacji implementuje się w C#. Microsoft opisuje WPF jako platformę obejmującą między innymi kontrolki, układ elementów, wiązanie danych, grafikę, animacje, tekst i style. Szczegóły znajdziesz w dokumentacji Microsoft Learn dotyczącej WPF. Największa różnica względem prostszych narzędzi polega na tym, że wygląd kontrolki i jej zachowanie można rozdzielić. Przycisk nie musi być tylko standardowym prostokątem, a lista nie musi wyglądać tak samo jak w każdej innej aplikacji. Dzięki stylom, szablonom i wiązaniu danych można zbudować zarówno panel administracyjny, jak i rozbudowane narzędzie dla pracowników.

Trzeba jednak od razu postawić ważną granicę. WPF jest technologią windowsową, więc aplikacja nie uruchomi się natywnie na macOS ani Linuxie. Jeżeli docelowo program ma działać na kilku systemach, wybór WPF będzie kosztownym ograniczeniem już na początku projektu.

Najważniejsze elementy WPF

• XAML opisuje strukturę i wygląd interfejsu.
• Code-behind pozwala obsługiwać zdarzenia bezpośrednio w pliku okna lub kontrolki.
• Data binding łączy właściwości kontrolek z obiektami C#.
• Style i ControlTemplate umożliwiają zmianę wyglądu bez przepisywania logiki.
• Dependency properties rozszerzają zwykły mechanizm właściwości i są podstawą wielu funkcji WPF.
• Routed events pozwalają obsługiwać zdarzenia na różnych poziomach drzewa elementów.

W praktyce oznacza to dużą swobodę, ale również większą złożoność. Początkujący często oczekuje, że WPF będzie tylko nowocześniejszym WinForms. Tak nie jest. To bardziej rozbudowany model pracy, który zaczyna naprawdę procentować przy aplikacjach mających wiele ekranów, różnych źródeł danych i własny system wizualny.

Jak utworzyć pierwszy projekt WPF w C#

Najprostsza droga prowadzi przez Visual Studio z zainstalowanym obciążeniem Programowanie aplikacji klasycznych .NET. Przy tworzeniu projektu wybierz szablon WPF Application, a nie wariant oparty na starym .NET Framework, chyba że rozwijasz istniejący system wymagający tej wersji.

1. Uruchom Visual Studio.
2. Wybierz utworzenie nowego projektu.
3. Wyszukaj szablon WPF Application.
4. Wybierz aktualnie wspieraną wersję .NET z oznaczeniem Windows.
5. Uruchom projekt i otwórz plik MainWindow.xaml.

W projekcie pojawią się zwykle pliki App.xaml i MainWindow.xaml. Pierwszy definiuje zasoby oraz punkt startowy aplikacji, drugi opisuje główne okno. Towarzyszący mu plik MainWindow.xaml.cs zawiera klasę C#, która może obsługiwać zdarzenia i logikę związaną z tym oknem.

Obsługa zdarzenia może wyglądać tak:

private void OnButtonClick(object sender, RoutedEventArgs e)
{
    MessageBox.Show("Przycisk został kliknięty.");
}

Taki kod jest dobry na początek i do małych narzędzi. Nie budowałbym jednak całej aplikacji biznesowej na dziesiątkach metod obsługujących kliknięcia. Z czasem kod odpowiedzialny za interfejs, dostęp do bazy i reguły biznesowe zaczyna się mieszać, a każda zmiana wymaga ostrożnego sprawdzania wielu plików.

XAML, wiązanie danych i odpowiedzialność C#

Najważniejszym mechanizmem odróżniającym WPF od prostszych frameworków jest wiązanie danych. Kontrolka może pobierać wartość z właściwości obiektu C#, a zmiana tej właściwości może automatycznie zmienić interfejs. Microsoft opisuje binding jako sposób na połączenie elementów UI z obiektami .NET i kolekcjami danych.

Przykładowo, pole tekstowe może być związane z właściwością Query, a etykieta z liczbą wyników:

W tym przykładzie interfejs nie musi sam odczytywać tekstu z kontrolki po każdym zdarzeniu. WPF korzysta z właściwości DataContext, aby znaleźć obiekt udostępniający Query i ResultsCount. To ogranicza liczbę bezpośrednich zależności między kodem C# a konkretnymi kontrolkami.

Żeby interfejs reagował na zmiany, obiekt powinien zwykle implementować INotifyPropertyChanged. Dla list przydaje się ObservableCollection, ponieważ informuje widok o dodaniu lub usunięciu elementu.

public class SearchViewModel : INotifyPropertyChanged
{
    private string _query = string.Empty;

    public string Query
    {
        get => _query;
        set
        {
            if (_query == value)
                return;

            _query = value;
            PropertyChanged?.Invoke(
                this,
                new PropertyChangedEventArgs(nameof(Query)));
        }
    }

    public int ResultsCount { get; private set; }

    public event PropertyChangedEventHandler? PropertyChanged;
}

Sam mechanizm bindingu nie rozwiązuje wszystkiego. Trzeba pilnować nazw właściwości, typów danych i momentu aktualizacji wartości. Najczęstszy błąd to cichy brak danych w widoku, gdy ścieżka bindingu jest literówką albo obiekt nie został ustawiony jako DataContext. WPF często zgłasza taki problem w oknie Output, a nie jako wyjątek zatrzymujący aplikację.

Dlaczego MVVM ma znaczenie w większej aplikacji

MVVM, czyli Model-View-ViewModel, rozdziela aplikację na trzy części. Model reprezentuje dane i reguły domeny, View opisuje interfejs w XAML, a ViewModel przygotowuje dane oraz operacje, które może wykonać użytkownik. Dzięki temu okno nie musi wiedzieć, czy dane pochodzą z SQL Servera, pliku JSON czy usługi Azure.

W prostym kalkulatorze można spokojnie użyć code-behind. Sam często zaczynam od takiego rozwiązania, kiedy sprawdzam pomysł albo buduję jednorazowe narzędzie. Gdy pojawiają się trzy lub więcej ekranów, walidacja, asynchroniczne operacje i kilka źródeł danych, przejście na MVVM zwykle oszczędza czas, zamiast go zabierać.

Przeczytaj również: Port 3389 w RDP - jak sprawdzić i zmienić go bezpiecznie?

Co trafia do poszczególnych warstw

Do komend można wykorzystać własną implementację ICommand albo bibliotekę CommunityToolkit.Mvvm. Nie chodzi jednak o to, aby instalować pakiet do każdego małego projektu. Najważniejsza jest czytelna granica między interfejsem a logiką, a nie sama nazwa użytej biblioteki.

MVVM nie powinno też oznaczać tworzenia ogromnej liczby abstrakcji. Jeżeli każda właściwość ma osobny interfejs, fabrykę i warstwę pośrednią, prosty ekran staje się trudniejszy do zrozumienia niż potrzebuje. Architektura ma pomagać w zmianach, a nie imponować liczbą plików.

WPF, WinForms czy WinUI

Wybór technologii zależy przede wszystkim od wieku projektu, oczekiwanego wyglądu i planów dotyczących platformy. Wszystkie te rozwiązania pozwalają tworzyć aplikacje Windows w C#, ale różnią się modelem pracy.

Jeżeli rozwijasz istniejący system napisany w WPF, nie widzę powodu, aby przepisywać go tylko dlatego, że pojawiła się nowsza technologia. Dojrzała aplikacja z działającym zespołem, testami i użytkownikami często więcej zyska na modernizacji kodu niż na kosztownej migracji.

Przy nowym programie przeznaczonym wyłącznie dla Windows warto porównać WPF z WinUI 3. Microsoft wskazuje WinUI 3 jako kierunek dla nowych natywnych aplikacji Windows, podczas gdy WPF pozostaje dojrzałym frameworkiem dla aplikacji desktopowych i modernizacji istniejących rozwiązań.

Typowe problemy, które wychodzą dopiero w produkcji

Pierwszym problemem jest blokowanie wątku interfejsu. Operacja trwająca kilka sekund, na przykład zapytanie do API albo duży odczyt z bazy, wykonana bezpośrednio w obsłudze kliknięcia zamrozi całe okno. WPF korzysta z jednego głównego wątku UI, dlatego długie zadania powinny być wykonywane asynchronicznie, a interfejs powinien pokazywać stan ładowania.

Drugim problemem jest zbyt duża liczba elementów w widoku. Wielokrotnie zagnieżdżone panele, ciężkie szablony i brak wirtualizacji mogą sprawić, że lista kilku tysięcy rekordów zacznie działać ociężale. W przypadku dużych kolekcji trzeba sprawdzić DataGrid, VirtualizingStackPanel i sposób filtrowania danych, zamiast przenosić całą bazę do pamięci.

Kolejna pułapka to mieszanie dostępu do danych z kodem okna. Początkowo wygląda to wygodnie, bo wszystko jest pod ręką. Po kilku miesiącach zmiana zapytania, dodanie testów lub wykorzystanie tych samych danych na innym ekranie staje się jednak niepotrzebnie trudne.

• Nie wykonuj długich operacji synchronizacyjnie na wątku UI.
• Nie wkładaj zapytań SQL bezpośrednio do metod obsługujących przyciski.
• Nie ignoruj ostrzeżeń bindingu w oknie Output.
• Nie twórz osobnego mechanizmu stylów dla każdego ekranu, jeśli wystarczą zasoby aplikacji.
• Nie zakładaj, że aplikacja będzie dobrze wyglądać na każdym DPI bez sprawdzenia skalowania.
• Nie mieszaj starego .NET Framework z nowym .NET bez konkretnego powodu.

Osobno trzeba potraktować wdrożenie. Aplikację można dostarczać jako zależną od zainstalowanego środowiska .NET albo jako self-contained, czyli z dołączonym runtime. Pierwsza opcja zwykle daje mniejszy pakiet, druga ogranicza ryzyko, że na komputerze użytkownika zabraknie właściwej wersji środowiska. Wybór zależy od tego, kto administruje komputerami i jak wygląda proces aktualizacji.

Kiedy WPF będzie rozsądnym wyborem

WPF pasuje do aplikacji, która ma działać na Windows przez kilka lat, korzysta z rozbudowanego interfejsu i wymaga wygodnej pracy z danymi. Dobrze sprawdza się w systemach dla firm, narzędziach produkcyjnych, aplikacjach finansowych, panelach administracyjnych i programach współpracujących z urządzeniami.

Największą wartość daje tam, gdzie potrzebujesz dużej kontroli nad interfejsem bez rezygnacji z produktywności C#. Możesz zacząć od prostych kontrolek, a później dołożyć walidację, własne szablony, obsługę skrótów klawiaturowych, grafikę, animacje czy integrację z usługami sieciowymi.

Nie wybierałbym WPF do projektu, którego najważniejszym wymaganiem jest jednoczesna obsługa Windows, macOS i urządzeń mobilnych. W takiej sytuacji ograniczenie platformy pojawi się bardzo szybko i będzie wpływać na architekturę, testy oraz koszty utrzymania.

Dobry start z WPF zależy bardziej od architektury niż od wyglądu

Najrozsądniejszy plan to zacząć od małego, działającego ekranu, ale od początku pilnować podziału odpowiedzialności. Interfejs buduj w XAML, dane trzymaj w modelach i serwisach, a dla większej aplikacji użyj ViewModeli oraz komend.

Sam nie przywiązywałbym nadmiernej wagi do efektownych animacji na początku projektu. Znacznie większą różnicę robią poprawne wiązanie danych, responsywność, obsługa błędów i łatwe wdrażanie. Jeśli te elementy są dobrze zaprojektowane, wygląd można dopracować później bez przepisywania całego programu.

WPF nie jest najprostszą drogą do każdego rodzaju aplikacji, ale w świecie windowsowych programów biznesowych pozostaje praktycznym i dojrzałym narzędziem. Przy właściwie dobranym zakresie, sensownym MVVM i świadomym podejściu do ograniczenia platformy pozwala budować aplikacje, które są wygodne dla użytkownika i możliwe do rozwijania przez lata.