Wstęp
Pod koniec maja br. postawiłem przed sobą pytanie, które męczyło mnie od dłuższego czasu oraz doszedłem w swojej pracy zawodowej do takiego momentu, że muszę sprecyzować swoje zainteresowania i ustalić konkretniejszą ścieżkę rozwoju dla siebie i dla działu programistycznego, który prowadzę (i którego jestem jedynym członkiem). Mój dylemat wyboru technologii jest następujący:
Hipoteza
Czy w 2022 roku można definitywnie wybrać najlepszą platformę programistyczną dostępną w dotnecie?
Krótka odpowiedź
Nie. Aczkolwiek na pewno można je podzielić na takie, których lepiej nie używać i takie, które lepiej używać, w zależności od specyfikacji projektu.
Długa odpowiedź
Stawiając sobie taką zagwozdkę do rozwiązania, doszedłem do wniosku, że z takich realistycznych możliwości można wybrać następujące cztery opcje:
- WinForms + płatna biblioteka UI (Telerik/DevExpress)
- ASP.NET Core MVC z Blazorem
- Avalonia UI + WebAPI
- WPF
Żeby dojść do jakiejś odpowiedzi, żeby móc wyciągnąć jakieś wnioski, zasięgnąłem porady od osób bardziej (ale może też mniej) doświadczonych ode mnie na Reddicie, Facebooku i Discordzie. Przygotowałem ankietę z platformami, które wydawały mi się na początku sensownymi opcjami, odrzuciłem UWP, które jest martwe, tak samo jak WebFormsy.
Może swoją analizę odpowiedzi zacznę od zebrania sumarycznych wyników ankiet:
W sumie było 1386 głosów, pojawiły się też pojedyncze odpowiedzi sugerujące m.in. MahApps.Metro, Syncfusion, MAUI, UWP, UNO Platform, Xamarin forms i WinUI.
Wychodzi zatem na to, że na ten moment, WPF jest najczęstszym wyborem platformy do tworzenia aplikacji w zamyśle desktopowych, ale powoli rozwiązania webowe zaczynają przejmować coraz większy kawałek zajętości rynku. WPF daje wiele możliwości i można stworzyć interfejs wyglądający w dowolny sposób. Blazor jest nowinką, ale w miarę przyjętą, za to MAUI to nowinka tak nowa, że nikt jeszcze nic poważnego w nim nie robi – a poza tym jest to biblioteka nastawiona najbardziej na urządzenia mobilne, która po prostu działa na komputerach. Więc w przypadku bardziej zaawansowanych aplikacji desktopowych może się nie sprawdzić. A poniżej opiszę każdą z tych 5 opcji, razem z tym, co udało mi się o nich dowiedzieć i sugestią, do jakich projektów ja bym ich używał.
Blazor
Blazor to platforma do tworzenia interaktywnych, webowych interfejsów. Tak w największym skrócie, jest to aplikacja webowa, w której we frontendzie można, zamiast JavaScriptu, używać C#. Powoli nowe projekty zaczynają wykorzystywać Blazora, wydajnościowo spisuje się naprawdę dobrze, a w internecie jest coraz więcej poradników jak z niego korzystać. Mimo wszystko zaleca się używania Blazora tylko do interfejsu graficznego, a cała logika biznesowa aplikacja powinna być postawiona osobno jako API. Chociaż serwer z kontrolerami też da się w Blazorze postawić.
WinForms + płatne biblioteki
WinForms to jedna z najstarszych platform do tworzenia projektów w C#, którą można już prawie nazwać nieśmiertelną. WinFormsy przeżyły kilku swoich „następców”, nadal są powszechnie wykorzystywane i nic nie zapowiada, żeby miały umrzeć. Prawdą jest, że już pewnie żaden nowowczesny, duży projekt już w WinFormsach nie powstanie, ale jest tak dużo starszych aplikacji, które nadal funkcjonują, więc zaznajomienie się z nimi to bardzo przydatna wiedza. Sam w sobie nie wygląda dobrze, ale istnieje dużo popularnych, ale płatnych bibliotek, które mogą z niego zrobić aplikację wyglądająca równie dobrze co nowe aplikacje Microsoftu, jak pakiet Office, czy inna desktopowa aplikacja. Jednak mimo to, ciężko utrzymać w nim bardziej skomplikowaną aplikację z zaawansowaną architekturą.
Niektórzy kochają WinFormsy, niektórzy nienawidzą, podobno innej opcji nie ma. Wybór jest prosty – robisz szybko coś prostego na komputer, bierz WinFormsa. Robisz coś, co wymaga bardziej skomplikowanych rzeczy? Trzymaj się z daleka.
Avalonia UI + WebAPI
Avalonia oparta jest na XAMLu, tak samo, jak WPF, Silverlight, WinUI, UWP, Xamarin, Uno, MAUI i pewnie wiele innych platform. Nie ma co się tutaj dużo rozpisywać. Każda z tych opcji polega na napisaniu interfejsu użytkownika w XAMLu i komunikowanie się z API, żeby zapewnić aplikacji jakąś logikę biznesową.
WebAPI – choć mimowolnie dzisiaj uniwersalnie określenie „API” od razu kojarzy się z API wystawionym gdzieś w sieci, to formalnie samo API może oznaczać również dll-kę do komunikacji z innym programem lub biblioteką na tym samym komputerze – a w sieci mamy WebAPI. Ta opcja polega na napisaniu serwera, do którego wysyłamy zapytania HTTP (np. wchodząc pod konkretny adres URL w przeglądarce), a w odpowiedzi dostajemy dane, które potrzebujemy.
ASP.NET Core MVC z Blazorem
Być może błędnie stworzyłem ten punkt w ankiecie – bo ASP.NET Core MVC może istnieć z Blazorem, może istnieć bez, tak samo Blazor może istnieć sam. A domyślnie w aplikacjach webowych ASP.NET interfejs robimy w razor-pages, czyli plikach .cshtml, gdzie oprócz HTMLa i JSa można coś dopisać w C#. Jednak w odróżnieniu od Blazora, razor-pages wykorzystują C# tylko do wygenerowania HTMLa jeszcze po stronie serwera. A Blazor może wykonywać ten kod po stronie klienta. ASP.NET można określić jako podstawę aplikacji webowych w C#. Najpopularniejszą architekturą jest MVC, gdzie głównym elementem są kontrolery – biorą one dane z modelu i wysyłają do widoku, który widzi użytkownik – tak w uproszczeniu.
Więc ASP.NET jest podstawowym budulcem aplikacji serwerowych w C#, a dostęp do tej aplikacji może być przez API, przez strony zrobione jako razor-pages albo przez strony zrobione w Blazorze.
WPF
Windows Presentation Foundation został wypuszczony w świat w 2006 roku, 4 lata po WinFormsach. Dzisiaj można już uznać, że przejął pałeczkę od WinFormsów jako podstawowa platforma do tworzenia aplikacji desktopowych w C#, choć trochę czasu to zajęło. Architektura jest prawie identyczna z WinForms – mamy jeden plik, który tworzy interfejs, i drugi, połączony z nim, który obsługuje ten interfejs. Tam obsługujemy wszystkie zdarzenia wywołane przez użytkownika i obsługujemy całą logikę aplikacji (oczywiście w zależności od podejścia i skali, może być to bezpośrednio, może być poprzez wywoływanie zaszytej w innych plikach logiki, lub komunikowanie się z API). Dodatkowo tak jak w WinFormsach, w WPFie również możemy skorzystać z bibliotek rozbudowujących możliwości interfejsu użytkownika.
Tę opcję sugerowałbym wybrać wszystkim, którzy mają konkretne argumenty na to, że ich aplikacja musi być aplikacją desktopową, a nie może być webową.
Podsumowanie
Ilu programistów, tyle rozwiązań. Na pewno przy tworzeniu własnej aplikacji, musisz zastanowić się, co ona ma robić, gdzie i jak ma być używana, bo od tego zależy, czy powinieneś zrobić aplikację desktopową, czy webową.
Jeżeli skłaniasz się ku desktopowi, to wychodzi na to, że najlepiej w 2022 roku zabrać się od razu za WPF, pomijając poczciwe WinFormsy (wow – jest to chyba jedyne definitywne stwierdzenie w całym artykule). Przy nowszych systemach, większych rozdzielczościach, WinForms po prostu przestaje już wyrabiać.
A jeżeli skłaniasz się ku aplikacjom webowym, to do wyboru, do koloru – jak chcesz również mobilkę, to na pewno zrób API, a interfejsów kilka, jeden na telefon, drugi na komputer. Jak nie potrzebujesz obsługi telefonóow, to też zależy, czy chcesz siedzieć tylko w C# i wybrać ASP.NET MVC, czy masz ochotę na coś innego, to oprócz API możesz też nauczyć się Reacta, Angulara, czy innych tych takich JavaScriptów do frontendu.
Gdy ktoś się postara w internecie, trzeba mu podziękować
Poniżej zamieszczam komentarz użytkownika u/Slypenslyde, który napisał bardzo konkretny komentarz na ten temat – warto go przeczytać.
Polecam, pozdrawiam, zapraszam.
Makary Rybiej
Dziękuję 🙂