Is it better to use WPF over Windows Forms?

前端 未结 11 1008
谎友^
谎友^ 2020-12-15 05:32

For a brand new application, is it better to use WPF over Windows Forms? I used Windows Forms before but not much WPF. As far as I know, WPF is the successor to Windows Form

相关标签:
11条回答
  • 2020-12-15 06:17

    I know this is an old post, but I think it's still a valid question.

    I used WinForms for 3 years at the first company I worked for. There were some really good programmers there, and they found some very clever ways to do some very cool things. WinForms has stood the test of time. It is a solid, reliable and efficient platform. Many people, and many companies both large and small have been using WinForms for years, and the technology has proven itself time and time again. Inertia like that is hard to fight, even if you are Microsoft.

    Still, WPF is definitely the future. Microsoft made that clear by making products such as Visual Studio 2010 and Expression Blend with it. (In using WPF for internal projects, Microsoft was forced to fix many of the issues, such as font rendering and speed issues, that prevented people from adopting it at first. Visual Studio 2010 shows that WPF has long been ready for production.

    So, is it better to write your program in WinForms or WPF? The answer is this : WPF. I say this for two reasons. Firstly, because Microsoft is supporting it internally, we can assume that it will be around for a very long time. Microsoft has shown us that it is the next tool of choice which leads me to my next point: it has become superior to WinForms (some people I have spoken to disagree, but it is the truth nonetheless, and is becoming more obvious every day). WPF has a host of features that WinForms will (probably) never be given, such as integrated support amazing data binding, and timeline based animations that make it easy to make amazing themes for your apps, and will have designers begging to make the switch. There is much more to WPF than can ever be described in a comment, but these are two big ones for me :)

    This being said, I know there is nothing you can do in WPF that you cannot do in WinForms. You can do anything in any language if you want to badly enough. The point is that where WinForm's will leave you scouring google for how somebody else did something cool, WPF ships with built-in support for all the features that Microsoft considers to be the future of Windows and puts them right at your fingertips.

    Over time, people will become used to new features build directly into Windows, and will come to expect them to be available in all the applications they use. This will reach the point where anything that doesn't support them will feel clunky, less usable, and seem less worth spending money on. (I see Touch integration as the most obvious example of this. Although there are touch screen solutions that clamp onto a monitor and emulate a mouse, on any computer, touch screen technology has come a very long way, and with Windows 8 blurring the line between the desktop and mobile devices, people will likely want to use applications in a way that will be exceptionally difficult to implement if your application uses WinForms.)

    Sooner or later, I believe that support and development for WinForms will stop, and everybody that left themselves behind will be forced to port, and quickly. However, there are too many programs out there that rely on WinForms for Microsoft to be able to drop it in the near future. Who knows what will happen. Perhaps WinForms will be to Microsoft what Itanium Processors are to Intel, the product that has enough users that to keep it going, even though there are better solutions available. ( http://arstechnica.com/business/news/2011/06/ask-ars-why-itaniumask-ars-with-xeons-improvement-why-bother-with-itanium.ars )

    So my advice would be this: regarding new development, make the switch to WPF. Send some staff on training courses, or let them play for a while so they can get a better feel for the technology. The learning curve is going to be steep, but doing this will increase your team's skill set because by learning WPF, they will also be well on their way to learning SilverLight, which is similar enough to WPF for people familiar with WPF to be be able to learn it quickly, but is designed for the web rather than the desktop. This is valuable because apps rewritten in WPF will far easier to convert to Web Apps later down the line. WPF is new, but it was made for a reason, not simply for the sake of making something else for people to learn. It was designed to make applications more user friendly, intuitive, and portable. It was designed to help developers make their applications fit into the new age of computers.

    Regarding applications written in WinForms : I think it's safe to assume that WinForms will still be supported for quite a long time simply because of the amount of support it has gained. I would recommend letting your team familiarize themselves with WPF, and slowly start moving your applications over to WPF. Take all the time that Microsoft allows and don't rush the process, but always keep in mind that, one way or another, WinForms day's are over, and although nobody can be sure what will happen, support for the legacy product will be dropped as soon as it can be justified. Even if WinForms applications are kept around for many years, it is important to remember that times are changing, and we all need to change with them.

    0 讨论(0)
  • 2020-12-15 06:19

    If you're writing lots of custom controls I would choose WPF. Part of WPF's design is to be extendable, composable and the result is that it's dirt simple to write custom controls.

    I've done a bit of custom control writing in WinForms and it can be very challanging at time. Layout will really take some time away from you. Several weekends of my life were paid to WinForm Control Layout. Writing the equivalent controls in WPF was a cinch.

    0 讨论(0)
  • 2020-12-15 06:25

    Having just recently done a very similar product (3d viewer for mining data in WPF) I can definitely recommend WPF/SlimDX.

    The tools are a bit lax (especially Visual Studio), but WPF makes it much easier to make an app with a bit of Zing, rather than the default control grey that most things have.

    Using D3DImage from 3.5SP1 it's very easy to host a SlimDX device inside a control.

    Overall I'd say WPF isn't better to use, just different. Some things are better, some are worse. But it's definitely the future.

    0 讨论(0)
  • 2020-12-15 06:25

    For what it's worth, it's 2020, and I have written desktop applications in both WPF using MVVM and Windows Forms. I must say that I do not miss writing boilerplate type of code for WPF, such as classes for Converters, using some sort of event mediator to communicate between views, Commands, etc. Using MVVM Light can help with that problem. I like the clean separation of code in WPF/MVVM, but for small projects, I think the ability to very quickly push out a Windows Forms application cannot be understated. For graphic intensive applications, WPF will perform better than Windows Forms.

    These days, I tend to lean towards web development when possible since the web is available anywhere there's a network connection. Of course, web development typically has a longer product delivery as well. A positive, is that the C# that you already know, can translate to development in ASP.NET.

    0 讨论(0)
  • 2020-12-15 06:30

    ----EDIT 2 -----

    Given that you're trying to make an editor like the one you showed, I'd recommend going WPF even more. My current project has many features along those lines, as well, and we've decided that the ability to composite WPF with Direct3D content is extremely powerful. It's nice to be able to render your scene into anything - not just a rectangular window. In WinForms, you pretty much were limited to one rectangle, and you had issues with airspace there, too (subtle, but things like flickering issues when menus pull over your hwnd, etc). The WPF compositor with D3DImage gets rid of all of those issues, and lets you use your imagination to construct a very flexible UI. Things like rendering your scene in realtime on the side of a WPF3D object are possible, or using WPF controls directly on top of your d3d scene instead of trying to do the GUI in D3D, etc.

    -----Original---------

    If you're going to be hosting DX, you might want to consider it - especially since it gives you the ability to do scene composition with your UI and no airspace issues if you use D3DImage.

    This does work with SlimDX and WPF.

    ----EDIT-----

    For more information on the disadvantages of using Direct3D with Winforms, and the advantages of WPF/DX integration, see:

    MSDN Article on Airspace

    Codeproject arcticle on intro to D3DImage

    0 讨论(0)
提交回复
热议问题