Opfølgning på WPF-foredrag del 1 – Hvorfor WPF?
Som lovet vil jeg prøve at følge op på mit oplæg til, hvad WPF er og hvorfor det er en god ide at bruge det.
Nu er jeg efterhånden blevet spurgt en del gange, hvorfor man som Windows Forms udvikler bør skifte til WPF. WPF er fra Microsofts side primært blevet solgt som en grafisk platform – og ikke så meget rettet mod LOB (Line of Business). Det er overhovedet ikke berettiget, men der er et skær af “det er Web 2.0 versionen af Windows Forms – bare uden alle de rare kontroller”.
Problemet i den sammenhæng mener jeg er, at det er slet ikke grafikken, der gør WPF rar at arbejde med for udviklere. Ja, det er nemmere at arbejde med grafik – og vi har nogle hidtil usete muligheder for at lave noget, der ser godt ud – men det er bare ikke WPF’s væsentligste styrke. Der hvor det rykker er på vedligeholdelsessiden. Når man lige skal skifte fra et DockPanel til et Grid Layout foregår så uhyggelig meget nemmere end Panel og Docking/Anchors i Windows Forms.
Der er ikke en masse, der er ‘gemt’ i InitializeComponent, som man ikke skal pille i, fordi det bliver overskrevet af designeren. Der skal ikke laves fiks-fakserier med custom controls for at få default værdier til at gælde for alle af en given type kontrol. Det er muligt at lave udseendet af en kontrol om uden at skulle fifle med GDI+… listen bliver bare ved og ved. WPF er opbygget som CSS – og det giver nogle virkelig stærke muligheder for at styre layoutet centralt.
Derudover er der en stor pointe med hensyn til at mindske forskellen mellem web- og applikationsudvikling. Syntaksen er fuldstændig ens med Silverlight, så det er nemt at skifte mellem de to teknologier til forskellige projekter (der er dog stadig små semantiske og enkelte tekniske forskelle). I min optik er det en kæmpe fordel for en udvikler, at hun kan skifte umiddelbart mellem to de (traditionelt) adskilte verdener.
I del 2 vil jeg kort forklare hvad databinding går ud på, og hvorfor det er så essentielt for WPF-udviklere.