Cztery lata temu, popełniłem post „Zapomnijcie o windows forms”. Po czterech latach i wielu innych technologiach po drodze wracam do tematu.

Ostatnio miałem okazję napisać mała aplikację w WPF, to był raczej test, a nie aplikacja dla klienta, jednak nie zmienia to faktu, że musiałem przysiąść i to napisać :) Nie wiem czy to tylko mnie tyczy, czy są też inni ludzie którzy podobnie myślą, ale osobiście nie zobaczyłem, żadnych pozytywnych zmian w tej technologii mimo upływu 48 miesięcy.

Oczywiście, toolset jest już dużo lepiej dopracowany, VS nie twierdzi, że brakuje mu pamięci jak tylko włączam edytor czy to XAMLa czy też graficzny. R# robi swoje i pomaga dodatkowymi funkcjami i refactoringiem, jedna z zajebistych opcji to jest na przykład generowanie kodu:

public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
    var handler = PropertyChanged;
    if (handler != null)
    {
        handler(this, new PropertyChangedEventArgs(propertyName));
    }
}

Który wykonuje się tak:

private string _value;
public string Value
{
    get { return _value; }
    set
    {
        _value = value;
        OnPropertyChanged(); // no magic strings! no lambda! lol
    }
}

Ale znów, to jest feature C# a nie WPF.

Także to co WPF umożliwiał za pomocą XAMLa dalej uważam, za coś super fajnego, to, że można tworzyć elementy tak jak się chce, stylować je jak się chce i to wszystko łączyć w jedną piękną całość jest po prostu super. Oczywiście XAML jest trochę moim zdaniem za bardzo ekspresywny trzeba naprawdę dużo się naklepać – no chyba, że korzysta się z takich narzędzi jak Blend itp. Tak czy siak, niezależnie od tego jak bardzo byśmy chcieli to skrócić czasami się po prostu nie da. Ustawienie domyślnej czcionki dla całej aplikacji? Zapomnijcie, bez jakiś atrybutów BasedOn, i wielu Style tagów dla konkretnych typów elementów czcionki się łatwo nie da zmienić. W ogóle, ustawienie koloru czcionki zawiera X znaków:

<SolidColorBrush x:Key="DarkSomething" Color="#121515" />
<Style x:Key="Display" TargetType="{x:Type TextBlock}">
    <Setter Property="Foreground" Value="{StaticResource DarkSomething}" />
</Style>

To już chyba mała przesada :)

I tutaj nagle wychodzi to, co przez ostatnie 4 lata MS mógł zrobić, ale nie zrobił. Próbowałem znaleźć informacje o tym co się zmieniło w WPF ale natrafiłem jedynie na post z 2012 roku, w którym jest informacja, że nic się nie zmieniło. I pewnie nie licząc zmian wypisanych tutaj to się nic nie zmieniło.

Nie licząc tego co pisze MS, ja w 2010 roku pisałem kontrolkę dla TextBox, która umożliwia wstawienie placeholder – tak jak w HTML. Co teraz robiłem? Dosłownie to samo, zresztą google pokaże wam wiele innych rozwiązań. Albo, jak zrobić by wyjątki złego bindowania były wyrzucane? Nic prostszego, napiszmy kod… wat? tak… musimy to sami zaimplementować (sic!)

Zastanawia mnie fakt, że naprawdę fajna dość technologia MS, została porzucona troszkę przez MS (albo mam takie wrażenie po tym co czytałem i próbowałem znaleźć), mimo iż jest ona wykorzystywana w Windows Phone i Windows Apps. Czyżby MS zamiast koncentrować się na rozwijaniu tego co ma, stwierdził, że z koncentruje się na rozwijaniu kontrolek dla określonych urządzeń?

Ale XAML to tylko jedna strona całości. Fajnie jakby był mniej ekspresywny i dawał kilka rzeczy z miejsca a nie oczekiwał, że każdy będzie to pisał.

Drugą stroną jest ten piękny ukochany wzorzec przez wszystkich maniaków SL, WPF i Knockout – MVVM. Wzorzec dla którego istnieje minimalne wsparcie w WPF, a który wymaga od każdego z nas ekstra pracy, ekstra kombinowania, i rozgryzania – ten dialog, to jak go pokazać? Jako serwis go wstrzyknąć? A jak zrobić regiony? Jak załadować coś tylko w miejscu X i jak do tego przekazać komendę którą ten kod ma wykonać? A jak się już to rozwiąże to pojawi się X osób które powiedzą, że powinno się to zrobić inaczej bo się łamie zasady MVVM.

Do tego jeszcze dochodzi to przeklęte dziedziczenie – albo powtarzanie tego samego kodu (20-30 linijek) do INotifyPropertyChanged, IDataErrorInfo cały czas, a potem jeszcze należało by obsłużyć special case, że może istnieć model bez walidacji.

Im więcej się w tym siedzi, tym więcej znajduje się problemów a nie rozwiązań. Nie jestem aż tak bardzo przeciwny MVVM, ale wolałbym widzieć wsparcie po stronie WPFa a nie po stronie bibliotek, którą są napisane X lat temu, nie zawierają dokumentacji, przykładów albo po prostu są lub wydają się zapomniane – na przykład Prism (ostatni release 4 lata temu), WPF Toolkit (też 4 lata temu aktualizowany).

Weźmy dla przykładu osobę zaczynającą pisać w WPF, która by chciała wykorzystać MVVM Light. Jak myślicie co ta osoba musi zrobić by się dowiedzieć jak z tego korzystać? Ma kilka opcji:

· Spędzić kilka godzin googlując i szukając przykładów – których za dużo nie ma, albo były ileś lat temu

· Spędzić godzinę googlując i resztę na patrzeniu w kod biblioteki

Wtedy może będzie szansa, że się czegoś nauczy. Ale czy będzie wiedziała jak to wykorzystać? Wątpię. W ogóle szukając i patrząc w net, o WPF bardzo mało byłem wstanie wyczytać – albo natrafiłem na blog posty z przed X lat.

Podsumowując, moja aplikacja, którą pisałem zawiera 500 linijek kodu logiki biznesowej, 1 000 linii XAML plus około 400 style, zaś reszta 2 000 linii to kod zbędny, który wszystko łączy w całość, deklaracja komend, handlery do komend, pełne implementacje własności (zamiast auto) itp. To już jest przesada i to ogromna. Ten sam kod w MVC to 500 linijek kodu logiki, 400/500 HTMLa, 300/400 CSS i jedynie 500 kodu łączącego z czego tak naprawdę 1/3 to deklaracja klas i metod.

Oczywiście, ciężko to porównywać, ale różnicę widać i czuć. Mimo wszystko WPF jest dość ciekawy i podoba mi się to, co mogę zrobić w UI i jak to mogę zrobić, choć nie pochwalam liczby linii kodu, którą muszę wystukać by coś mi działało lub nie.

Mam nadzieję, że za cztery lata będę mógł napisać bardziej pozytywny post, czas pokaże. Tym czasem, ludzi pracujących z WPF, proszę o jedno – piszcie posty, pokazujcie jak coś można zrobić lub napiszcie tutoriale dla początkujących. Wtedy może za te 4 lata, WPF się zmieni i będzie on w końcu bardziej przyjazny początkującym, jak i tym którzy już z nim od wielu lat pracują.

13 KOMENTARZE

  1. Ostatnio miałem dokładnie ten sam problem. Ostatecznie zdecydowałem się na Caliburn.Micro. Ale nie zmienia to faktu że WPF powinien mieć to by design.

  2. WPF super technologia niestety obawiam się że może skończyć jak SL. Gdzieś przeczytałem, że ok 4000 błędów które zostały zgłoszone już nigdy nie zostaną poprawione. Po wpf’ie zostanie jedynie xaml.

  3. Była sobie kiedyś technologia, która miała zalety WPF i eliminowała jego wady – a przynajmniej część. Nazywało się to Flex (no nadal jest, żeby nie było). Posiadał(a) cuda, które czynią WPFa użytecznym (kompozycja) oraz można to było stylować pseudo CSSem. Super sprawa, nie bez wad, ale zawsze.
    Można mieć nadzieję, że coś podobnego jeszcze się zrodzi. Choć patrząc jak M$ promuje HTML’a w Win8….

  4. Niestety, wielu programistów z którymi rozmawiałem na temat WPF uważa, że on po prostu umiera :/ Wielka szkoda. Aplikacje desktopowe pewnie będą powstawać jeszcze przez wiele lat, ale sam microsoft chyba tak nie uważa. Widać to w np. ostatniej aktualizacji VS – nie było chyba żadnej zmiany w WPF, XAML itd, coś tam poprawili w Windows Phone i to chyba wszystko – cała reszta to Web.

  5. Za bardzo skupiacie się na samej nazwie WPF czy SL, sama idea i XAML istnieje i są bardzo prężnie rozwijane, o czym może świadczyć fakt, że XAML stał się natywną częścią Windows’a możemy pisać aplikacje w C++ korzystające z XAML’a.
    W tej chwili nie obserwuje się rozwoju samego WPF’a, kierunek jest zgoła inny. Kierunek jest taki, aby nie korzystać z oddzielnego API jak WinRT czy API Windows Phone’a, a żeby z użyciem dokładnie tych samych linii kodu wyprodukować aplikację, która będzie działała na różnych platformach sprzętowych.
    WPF jako technologia będzie zanikać, ale tak samo jak zapewne będzie zanikać część desktopowa Windowsa na rzecz kafelków… (mam swoje przemyślenia na ten temat ale nie mi oceniać czy jest to dobre przesunięcie).

    A tak na marginesie WPF sam w sobie jest zajebisty i ze świeczką szukać platformy gdzie szybciej i łatwiej się napisze aplikację, ASP.NET MVC? No proszę Panowie, bez przesady. Bardzo lubię ASP.NET MVC ale jeżeli chcemy zrobić jakikolwiek wodotrysk to nie obejdzie bez pisania w JS – co już do przyjemnych nie należy. Może i sumarycznie wyszło dla Gutka mniej linii kodu ale wolę napisać stronę XAMLa nawet bez intellisense (tutaj też się trochę rzeczy poprawiło) niż kilka linijek w JS :)

  6. W sumie każdy z akapitów tego posta można by wypunktować, ale czasu brak. Kto ma korzystać w wpfa… ten i tak to robi.

    Objętościowo pół posta zajmuje krytyka mvvm/inotifypropertychanged/idataerror: polecam http://www.postsharp.net/

    Każda firma (czasami na bazie jakiegoś istniejącego, np prism) buduje własny framework do tworzenia apek w wpfie. Może bariera wejścia w tą technologię jest duża, ale jak się wszystko poskłada do kupy to dostajemy możliwość szybkiego tworzenia skomplikowanych aplikacji.

  7. **@Marcinii**

    WPF jest spoko o czym wpsomanilem, szkoda ze nie jest dalej rozwijany przez MS by ulatwic nam zycie a nie kazac nam za kazdym razem hackowac wszystko :)

    Co do JS ;) no, to trzeba lubic ;) ale i latwo da sie przestawic ;)

    **@kowal**

    zauwaz, ze nie narzekam na to ze trzeba implemntowac interfejsy itp, mowie tylko ze nie dochodzi dziedziczenie lub powtarzanie kodu. Do tego, krytyka Inotify etc zajmuje… jeden akapit. A brak wsparcia dla MVVM bezposrednio w jezyku duzo wiecej. Jakos tez nie krytykowalem MVVM a wsparcie dla niego – chyba ze _ Nie jestem aż tak bardzo przeciwny MVVM, ale wolałbym widzieć wsparcie po stronie WPFa a nie po stronie bibliotek_ to jest krytyka calosciowa MVVM.

    To ze istnieje postsharp wiem, ale jego wykorzystanie zalezy od tego na co firma sie godzi a na co nie. Wiem, tez ze istnieje RavenDB i Simple.Data – ale tego tez nie moge wykorzystac.

    Super, ze firmy buduja wlasne frameworki do WPF, ale szkoda, ze musza to robic by zapelnic dziury ktore przez te wszystkie lata moglyby byc zapelnione (lub czesciowo zapelnione). Glownie chodzi o to, ze cos co bylo zajebiste 4 lata temu (przeczytaj podlinkowany post), nie zmienilo sie. Wciaz jest to samo. A nie zaszkodzilo by dodac parenascie rzeczy do tego framework/xaml by ulatwic prace kazdemu dev.

  8. Myślę, że Gutkowi właśnie o krytykę XAMLa chodziło. Zgadzam się, że jest to najlepsze co istnieje, ale jest mu daleko od bycia idealnym. Tak jak napisano jest cholernie rozgadany, reużywalnośc kodu polega na jego kopiowaniu, stylowanie to udręka… Jak napisałem – jeżeli porównamy go do Flex’a… to wygoda programowaniu w WPFie jest mizerna

  9. @gutek:
    wpf ma być tylko maszynką do rendrowania. to, że zapewnia integrację np z inpc jest tylko możliwością. każdy inpc i inne składowe aplikacji biznesowych implementuje po swojemu, wiec po co wpf ma dostarczać jakieś zbędne dla “maszynki do rendrowania” bajery?

    @Michał: nic nie jest idealne dla wszystkich… jakoś nie zauważyłem, żeby teleriki używali metody kopiuj-makaron.

  10. Przepraszam, się nie znam, nie wczytywałem się, mleko kipi… ale nie można tego całego “OnPropertyChanged” jakimś aspekcikiem /proxy potraktować raz a dobrze?

Comments are closed.