TOC

This article is currently in the process of being translated into Swedish (~54% done).

About WPF:

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.

This was just one difference, but as you work with WPF, you will realize that it is in fact the underlying reason for many of the other differences - WPF is simply just doing things in its own way, for better and for worse. You're no longer constrained to doing things the Windows way, but to get this kind of flexibility, you pay with a little more work when you're really just looking to do things the Windows way.

The following is a completely subjective list of the key advantages for WPF and WinForms. It should give you a better idea of what you're going into.

WPF advantages

  • It's newer and thereby more in tune with current standards
  • Microsoft is using it for a lot of new applications, e.g. Visual Studio
  • It's more flexible, so you can do more things without having to write or buy new controls
  • When you do need to use 3rd party controls, the developers of these controls will likely be more focused on WPF because it's newer
  • XAML makes it easy to create and edit your GUI, and allows the work to be split between a designer (XAML) and a programmer (C#, VB.NET etc.)
  • Databinding, which allows you to get a more clean separation of data and layout
  • Uses hardware acceleration for drawing the GUI, for better performance
  • It allows you to make user interfaces for both Windows applications and web applications (Silverlight/XBAP)

WinForms advantages

  • It's older and thereby more tried and tested
  • There are already a lot of 3rd party controls that you can buy or get for free
  • The designer in Visual Studio is still, as of writing, better for WinForms than for WPF, where you will have to do more of the work yourself with WPF