WPF vs. WinForms

No capítulo anterior, falamos sobre o que é WPF e un pouco sobre WinForms. Neste capítulo intentarei comparar os dous, porque aínda que serven para o mesmo propósito, hai MOITAS diferenzas entre eles. Se nunca antes traballou con WinForms, e sobre todo se WPF é o seu primeiro framework GUI, pode omitir este capítulo, pero se está interesado nas diferenzas, siga a ler.

A diferenza máis importante entre WinForms e WPF é o feito de que, aínda que WinForms é simplemente unha capa encima dos controis estándar de Windows (por exemplo, un TextBox), WPF está construído desde cero e non depende dos controis estándar de Windows en case todas as situacións. . Isto pode parecer unha sutil diferenza, pero realmente non o é, o que definitivamente notará se xa traballou cun framework que depende de Win32 / WinAPI.

Un bo exemplo disto é un botón con imaxe e texto. Este non é un control estándar de Windows, polo que WinForms non che ofrece esta posibilidade. Pola contra, terás que debuxar a imaxe ti mesmo, implementar o teu propio botón que admita imaxes ou usar un control de terceiros. Con WPF, un botón pode conter calquera cousa porque é esencialmente un bordo con contido e varios estados (por exemplo, intocado, planeado, presionado). O botón WPF é "sen aspecto", como a maioría dos outros controis WPF, o que significa que pode conter unha serie de outros controis dentro del. ¿Queres un botón cunha imaxe e algo de texto? Simplemente coloque unha imaxe e un control TextBlock dentro do botón e xa está. Simplemente non obtén este tipo de flexibilidade dos controis estándar de WinForms, por iso hai un gran mercado para implementacións bastante sinxelas de controis como botóns con imaxes, etc.

O inconveniente desta flexibilidade é que ás veces terás que traballar máis para conseguir algo moi sinxelo con WinForms, porque foi creado só para o escenario para o que o precisas. Polo menos así se sente ao principio, onde te atopas creando modelos para facer un ListView cunha imaxe e un texto moi ben aliñado, algo que o WinForms ListViewItem fai nunha única liña de código.

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