Când vine vorba de aplicații client în familia .Net, Windows Presentation Foundation e un nume care apare tot mai des. WPF nu mai e o noutate, el fiind introdus încă din .Net Framework 3.0 dar aduce avantaje pe partea de interfață grafică care îl fac competitiv.
Tentația atunci când apare ceva nou, e de a-l face soluția ideală pentru orice problemă. Există o discuție continuă când vine vorba despre alegerea unei tehnologii client Microsoft, dar dacă nu se beneficiază de avantajele specifice aduse de WPF (data-binding, stilizarea dinamică, serviciile media, animații), din motive de performanță o mare parte din dezvoltatori încă aleg WinForms.
Modul declarativ a fost un succes în mediul de dezvoltare web și aceasta a inspirat un nou limbaj, bazat pe XML, numit eXtensible Application Markup Language (XAML). XAML are multe avantaje , dar ce merită menționat e că scapă de codul procedural și permite developer-ului sau chiar designer-ului, să descrie modul în care controalele arată și interacționează între ele.
View-ul în WPF conține un fișier XAML și unul de code-behind. Dacă e să urmăm pattern-ul MVVM și în design nu s-au facut compromisuri, în code-behind ar trebui să nu fie nimic mai mult decât ce e general automat iar legătura între datele din View și datele din ViewModel ar trebui realizata prin Binding.
Binding-ul este un mecanism puternic; el lansează notificările necesare pentru schimbari în UI automat atunci când reprezentarea datelor din ViewModel se schimbă.
În mod clar unul din avantajele pe care le aduce WPF-ul e extensibilitatea când vine vorba de customizare. Fiind cu un pas în fata WinForms-ului dacă vorbim de design, WPF-ul oferă dezvoltatorilor foarte multe posibilități și tehnici să schimbe look and feel-ul controalelor, iar acest lucru stă la baza aplicațiilor rich client moderne centrate pe user și modul de interacționare cu el.
Microsoft vine in întâmpinarea lor cu un tool orientat spre design, care are propriul build engine și e capabil să creeze applicații WPF separat de Visual Studio. Expression Blend separă puțin rolurile, oferind designerilor posibilitatea de a se focusa pe design, și programatorilor pe partea de cod (presentation logic sau back-end), conferind confortul de a nu se bloca unu pe celălalt.
În Blend aplicația e dezvoltată vizual, desenând pur și simplu forme, path-uri și controale pe planșa de lucru, ca mai apoi să fie descris modul de apariție și behavior.
În concluzie, dacă aplicația a fost aleasă să fie dezvoltată în WPF, este clar o nevoie de o interfață complexă, iar Blend aduce un mare ajutor pe această parte.
Model View ViewModel e un pattern UI, creeat de Microsoft ca o specializare a pattern-ului Presentation Model (introdus de Martin Fowler). Bazat în mare pe MVC, MVVM se preteaza mediilor de dezvoltare unde platforma de UI suporta event-driven programming, cum ar fi HTML, WPF, Silverlight.
Scopul acestui pattern e de a separa Interfața Grafică (fie ea markup sau cod) - View, de logica de business (backend) - Model. ViewModel-ul e responsabil să facă legătura între cele două, expunând datele din Model în așa fel încât să fie consumate de View, descriind în același timp logica.
MVVM a fost conceput să folosească data binding în WPF, pentru a facilita mai bine separarea de UI, renunțând în marea parte la code behind-ul din View. Avantajele sunt clar vizibile, și ar fi un pattern de urmat în orice aplicație dezvoltată în WPF.
Cu timpul, criticile nu întârzie să apară, iar una vine chiar de la John Gossman, inventatorul MVVM, care arată că aduce un overhead semnificativ dacă avem operații mari la nivel UI. Iar în cazul aplicațiilor mari cu UI complex, fine tuning-ul pe partea de View devine tot mai dificil de aplicat.
În WPF conceptul de controale stă la baza structurii UI-ului, și sunt create pentru a obține interfața grafică dorită si ar putea fi refolosite. De-a lungul timpului, au fost provideri care s-au consacrat, și probabil impus la nivel mondial prin setul de controale de WPF pe care îl oferă.
Controalele 3rd party pot fi pe de o parte o mare provocare / oportunitate pentru cei care doresc să le implementeze, pe de alta parte un mare ajutor pentru o echipă care dorește să implementeze o soluție rapidă la o problemă.
Din nevoia de a nu reinventa roata, pare o opțiune viabilă să achiziționezi un set de controale existent, care a dovedit de-a lungul timpului că îți aduce soluția de care ai nevoie. Printre marii dezvoltatori de controale de WPF se numără Telerik, Infragistics, DevExpress, care oferă o suită destul de diversificată de controale. Nivelul de experiență la care s-a ajuns în dezvoltarea acestor controale, e de multe ori greu de egalat, și probabil mult mai costisitor, iar prin aceasta persistă pe piața cam de când a aparut WPF-ul.
Una din tentațiile pe care le aduce setul de controale e suportul tehnic de care beneficiezi, contra cost, bineînțeles. Pe lângă documentația disponibilă abundent pe Internet, fiecare provider are un department tehnic și un mod prin care primești o lămurire la întrebările, nelămuririle și eventualele bug-uri legate de controale.
Dacă vorbim de aplicații industriale, performanța acestor controale este importantă și ea, ele find în mare parte black-box pentru consumatori. Se observă o anumită îngreunare dacă vorbim de un UI consistent, iar aceasta poate deveni o problemă.
Poate cel mai "problematic" control din punct de vedere al performanței e DataGrid-ul. Aceasta și din cauză că ține multe date spre a fi afișate. Majoritatea dezvoltatorilor de controale oferă căi pentru a face produsule lor performante. Ce ar trebui avut în vedere în acest sens:
Performanța e unul din aspectele cheie ce trebuie avute în vedere când se alege un set de controale, pentru a nu avea o aplicație matură cu un UI bogat, dar așa de înceată încât nimeni nu ar lucra cu ea.
WPF-ul e cunoscut pentru avantajele care de UI pe care le aduce, dar cum rămâne cu performanța? Am avut ocazia să lucrez pe mai multe proiecte WPF, din care două se remarcă pentru timpul de implementare lung și amploarea produsului în sine, unde performanța era una din necesitățile proiectului.
WPF nu a fost creat să fie performant "by design". Binding-ul e mecanismul care stă la baza WPF-ului, iar pentru realizarea fiecărui binding se ocupă memorie. Când se ajunge la screen-uri complexe, cu multe controale, în care fiecare subparte e legată de un obiect de date, se observă că exista și un cost pentru toate avantajele sale.
O altă problemă apare la date ierarhice, când se schimbă data context-ul. Propagarea se face descendent pe toate nivelele, și refacerea binding-urilor necesită timp. Acest aspect poate deveni vizibil pentru utilizator, iar o alternativă nu e tot timpul la îndemână. Din păcate, nu se mai vede un avans al Microsoft spre îmbunătățirea controalelor, dovada stă în faptul că cea mai bună îmbunătățire adusă în direcția aceasta în .Net Framework 4.5 e Virtualizarea la TreeView. Roadmap-ul pentru WPF nu poate fi confirmat decât în linii mari, așa că este neclar care e viitorul pe aceasta directie, ținând cont ca și Silverlight deși promițător la un moment dat, a fost brusc întrerupt.
Se întâlnește destul de des o paralelă între WPF și WinRT, și aceasta nu din motive nefondate. Amândouă au la bază XAML și un API asemănător, dar WinRT a fost gândit în manieră de performanță. A lăsat deoparte bagajul acumulat de WPF și are un API nativ în C++. Din C# (sau javascript) se apelează componentele native, iar acest lucru se simte în viteza de reacție.
În SDK-ul de Windows 7 se găsește o suită de programe de profiling, care dau posibilitatea de a analiza la run-time modul în care aplicațiile WPF se comportă și de a analiza ce optimizări se pot face pentru a spori performanța. În această suită se găsesc două componente care merită menționate.
Perforator - analizează modul în care se face rendering-ul aplicației. El afișează un set de grafice care dau posibilitatea de a analiza într-un mod foarte specific maniera în care se face rendering-ul fiecărei subpărți a unui screen si de a găsi eventualele probleme. Graficele oferite de Perforator constau în: analiza ratei de refresh, analiza schimbărilor intermediare care folosesc rendering-ul software, cel hardware și consumarea memoriei video.
Visual Profiler - prezintă problemele de performantă în contextul modului în care a fost construit layout-ul aplicatiei. Se parcurge ierarhia vizuală, și se vor întâlni obiecte high-level (cum ar fi butoane și TextBlock-uri) dar și cele low-level (cum sunt liniile și elipsele). În loc să descrie problemele de performanță arătând grafice, Visual Profiler descrie problemele folosind reprezentarea visuală a obiectelor (într-un mod similar cu cel în care funcționează UISpy ).
Comunitatea de dezvoltatori software e tot mai mare, și aceasta duce la o competiție tot mai acerbă între soluțiile software oferite. Cred că până la urmă, totul se va reduce la performanță. Acest criteriu va face diferența între un software utilizabil la scara largă și unul utilizat doar pentru că nu există alternativă. Modul de răspuns a unui program dă factorul de satisfacție necesar, iar utilizatorul începe să fie educat și să ceară tot mai mult în aceasta direcție.
en.wikipedia.org/wiki/Windows_Presentation_Foundation
en.wikipedia.org/wiki/Model_View_ViewModel
msdn.microsoft.com/en-us/library/cc296376.aspx
msdn.microsoft.com/en-us/library/188ht7d8(v=vs.80).aspx
en.wikipedia.org/wiki/Pareto_principle
msdn.microsoft.com/en-us/library/system.windows.data.binding.isasync.aspx
de Ovidiu Mățan
