WPF vs. WinForms

ໃນບົດທີ່ຜ່ານມາ, ພວກເຮົາໄດ້ເວົ້າເຖິງວ່າ WPF ແມ່ນຫຍັງ ແລະ ຄວາມຮູ້ເລັກໜ້ອຍກ່ຽວກັບ WinForms. ໃນບົດນີ້ ເຮົາຈະມາລອງປຽບທຽບລະຫວ່າງສອງສິ່ງນີ້, ເພາະວ່າໃນຂະນະທີ່ພວກເຂົາມີວັດຖຸປະສົງໃນການເຮັດວຽກຄືກັນ, ມີຫຼາຍຂໍ້ທີ່ແຕກຕ່າງກັນ ລະຫວ່າງ ພວກເຂົາ. ຖ້າເຈົ້າບໍ່ເຄີຍເຮັດວຽກກັບ WinForms ມາກ່ອນ, ແລະໂດຍສະເພາະ ຖ້າ WPF ແມ່ນ GUI Framework ທຳອິດທີ່ເຈົ້າຮຽນຮູ້, ເຈົ້າສາມາດຂ້າມບົດນີ້ໄປໄດ້ເລີຍ, ແຕ້ຖ້າວ່າ ເຈົ້າມີຄວາມສົນໃຈໃນຄວາມແຕກຕ່າງນີ້ ກໍ່ສາມາດອ່ານຕໍ່ໄດ້.

The single most important difference between WinForms and WPF is the fact that while WinForms is simply a layer on top of the standard Windows controls (e.g. a TextBox), WPF is built from scratch and doesn't rely on standard Windows controls in almost all situations. This might seem like a subtle difference, but it really isn't, which you will definitely notice if you have ever worked with a framework that depends on Win32/WinAPI.

A great example of this is a button with an image and text on it. This is not a standard Windows control, so WinForms doesn't offer you this possibility out of the box. Instead you will have to draw the image yourself, implement your own button that supports images or use a 3rd party control. With WPF, a button can contain anything because it's essentially a border with content and various states (e.g. untouched, hovered, pressed). The WPF button is "look-less", as are most other WPF controls, which means that it can contain a range of other controls inside of it. You want a button with an image and some text? Just put an Image and a TextBlock control inside of the button and you're done! You simply don’t get this kind of flexibility out of the standard WinForms controls, which is why there's a big market for rather simple implementations of controls like buttons with images and so on.

The drawback to this flexibility is that sometimes you will have to work harder to achieve something that was very easy with WinForms, because it was created for just the scenario you need it for. At least that's how it feels in the beginning, where you find yourself creating templates to make a ListView with an image and some nicely aligned text, something that the WinForms ListViewItem does in a single line of code.

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