WPF vs. WinForms

I det förra kapitlet pratade vi om vad WPF är och lite om WinForms. I det här kapitlet ska jag försöka jämföra de två, för trots att de fyller samma funktion finns det MÅNGA skillnader mellan dem. Om du aldrig arbetat med WinForms tidigare, och särskilt om WPF är ditt första GUI-framework, kan du skippa det här kapitlet, men om du är intresserad av skillnaderna, läs vidare.

Den enskilt viktigaste skillnaden mellan WinForms och WPF är att WPF är helt enkelt ett lager ovanpå standard Windows-kontroller (t.ex. TextBox), WPF är byggt från grunden och förlitar sig nästan aldrig på Windows standard kontroller. Det här kan tyckas som en subtil skillnad, men det är verkligen inte, vilket du definitivt kommer märka om du någonsin har arbetat med en ramverk som beror på Win32/WinAPI.

Ett bra exempel är en knapp med bild och text. Det är inte en standard Windows kontroll, så WinForms stödjer inte den möjligheten utan tillägg. I stället måste du själv rita bilden, implementera din egen knapp med stöd för bilder eller använda en tredjepartskontroll. Med WPF kan en knapp innehålla vad som helst för att det är i grund och botten bara en ram med innehåll och olika tillstånd(t ex orörd, svävande, klickad). WPF knappen är "look-less", liksom dom flesta andra WPF kontroller, vilket innebär att knappen kan innehålla en rad andra kontroller. Vill du ha en knapp med en bild och lite text? Lägg till en bild och en text i knappen och du är klar! Du har helt enkelt inte den här typen av flexibilitet i WinForms kontrollerna, därför finns det en stor marknad för ganska enkla implementeringar av kontroller som knappar med bilder och så vidare.

Nackdelen med den här flexibiliteten är att man ibland måste arbeta hårdare för att uppnå någonting som var väldigt lätt att uppnå med WinForms eftersom att det skapades för just det scenario som man behöver det för. Det är i varje fall så det känns till en början när man sitter och skapar mallar bara för att göra en ListView med en bild och lite fint justerad text, något som WinForms ListViewItem gör med en enda rad kod.

Det här var bara en skillnad, men medans du arbetar med WPF så kommer du inse att det faktiskt är det underliggande tankesättet för många av de andra skillnaderna - WPF gör helt enkelt saker på sitt egna vis, både på gott och ont. Du behöver inte längre känna dig inramad i att göra saker på "Windows sätt", dock betyder det även att du behöver investera en aning extra arbete om du faktiskt vill göra saker enligt Windows tillvägagångssätt.

Följande är en subjektiv lista som visar de främsta fördelarna med WPF och WinForms. Dessa borde ge dig en bra överblick över vad du kommer att ge dig in i.

Fördelar med WPF

• Det är nyare och därför mer aktuellt mot gällande standarder
• Microsoft använder det för många nya program, till exempel Visual Studio
• Det är mer flexibelt vilket gör att du kan göra mera utan att behöva skriva eller köra nya kontroller
• När du behöver använda tredjepartskontroller kommer utvecklarna av dessa sannolikt vara mer fokuserade på WPF just på grund av att det är nyare
• XAML gör det enkelt att skapa och ändra ditt användargränssnitt och tillåter arbetet att bli uppdelat mellan en designer (XAML) och en utvecklare (C#, VB.NET, osv.)
• Databinding, som tillåter dig att ha en renare uppdelning mellan data och layout
• Använder hårdvaruacceleration för att rita upp gränssnittet för en bättre prestanda
• Gör att du kan skapa användargränssnitt till både Windows-applikationer och webbapplikationer (Silverlight/XBAP)

Fördelar med WinForms

• Det är äldre och därigenom mer testat
• Det finns redan många tredjepartskontroller som du kan köpa eller få tag på gratis
• Design-verktyget i Visual Studio är fortfarande, när detta skrivs, bättre för WinForms än för WPF, där du behöver göra mer arbete själv i WPF