WPF与WinForms-Delphi程序员的观点？

我已经阅读了WPF与WinForms上的大多数主要线程，而我发现自己陷入了不幸的矛盾之中，当您在尝试使用过的和真正的先前技术（Winforms）以及它的后继技术（WPF）之间做出选择时，就会陷入这种矛盾中。

我是多年的资深Delphi程序员，最终终于跳到了C＃。我的其他Delphi程序员同伴将了解到，我很高兴知道Delphi闻名的Anders Hejlsberg是C＃的架构师。我对Delphi的VCL定制组件非常着迷，尤其是那些涉及制作多步向导和充当子组件容器的组件的组件。

在这种背景下，我希望从Delphi转到C＃的那些人可以帮助我完成WinForms vs. WPF决策，以编写初始应用程序。请注意，当我进行编码时，我非常急躁，诸如成熟的自动完成功能和适当的调试器支持之类的东西可能对我来说成败一个项目，包括能够找到有关API功能和调用的随时可用信息，甚至更多的错误解决方法。 。

2009年初日期范围内的SO线程和注释使我非常担心WPF，因为它可能会破坏我的C＃UI开发代码。另一方面，花费大量时间来学习即使没有被放弃也即将被替换的API技术（WinForms），同样令人不安，我确实在WPF诱人中发现了GPU支持。

因此，我的矛盾情绪。由于我还没有学过任何一种技术，所以我有一个难得的机会重新开始，而且不必面对巨大的“无学习”曲线，当WinForms程序员转向WPF时，我已经看到人们在各个线程中提到了这一点。另一方面，如果对像我这样的耐心的RAD开发人员来说，使用WPF太令人沮丧或产生其他严重的负面影响，那么我将坚持使用WinForms，直到WPF达到相同的支持水平和易用性。为了给您一个具体的例子说明我作为程序员的心理，我使用了VB，随后又使用了Delphi，以完全避免使用MFC进行编码的真正痛苦，MFC是许多开发人员在开发早期Windows应用程序时都会遇到的Windows UI库。我从未后悔避免使用MFC。

知道Anders Hejlsberg是否参与过WPF和/或WinForms的体系结构，以及这两个代码库中体现的创意视野和易用性方面是否存在差异，也令人感到欣慰。最后，再次让Delphi程序员知道使用WPF而不是WinForms时需要多少“ IDE schock”，尤其是在调试器支持方面。2011年更新的任何就业市场评论也将不胜感激。

如果您有Delphi的背景，您将对WinForms感到失望。您将尝试在VCL中做容易的事情，只是发现它们非常困难，甚至是不可能的。WPF的限制将大大减少。

例如，这只是我们遇到的一些WinForms限制：

• WinForms与TAction相比没有什么，因此，如果您习惯于使用动作进行编码，则在菜单项与工具栏按钮以及右键菜单之间共享相同的文本和图标，集中启用逻辑并更新启用状态在OnUpdate的后台运行...您会讨厌WinForms，在这种情况下，您必须采取所有困难且容易出错的方法。
• WinForms的旧（.NET 1.0老式）MainMenu不支持菜单项旁边的图像，而新的（.NET 2.0中引入的）MenuStrip 充满了 Microsoft 拒绝修复的错误（因为这些错误可能破坏向后兼容性）。
• 与VCL同类控件相比，许多控件（例如TreeView）的功能严重不足（痛苦极慢，没有所有者绘制，缺少许多自定义选项，等等）。
• 与您在Delphi中惯用的充满活力的第三方控件开发人员社区不一样。那里有质量控制库，但是您需要付费才能使用-像VirtualTreeView这样的免费产品就没有WinForms了。

在某些方面，WPF比WinForms更为简单，但它的可扩展性更大。

• 您想要TAction之类的东西吗？WPF具有ICommand，它与您以前使用的一样丰富（但请确保您阅读了Josh Smith的MVVM文章 -通常您必须在状态更改时手动启用/禁用命令，但是他的版本会自动触发启用代码在后台，就像您习惯使用OnUpdate）一样。
• 您想要菜单上的图像吗？这是内置的（而且没有WinForms那样的错误）。
• WinForms在一些重要的控件上省略了所有者绘图，但是如果您使用的是WPF，则不需要所有者绘图-如果您希望TreeView节点的黑色文本后跟一个带括号的蓝色数字，您只需将其放在您的DataTemplate中即可使用，不需要丑陋的所有者绘制代码。
• 您想要第三方控件吗？在许多情况下，您不需要它们，因为您可以用WinForms扩展现有内容，是的，VCL开发人员只能梦dream以求。

WPF的学习曲线非常陡峭，但是如果您拿起一本好书（例如“ WPF 4 Unleashed ”），它将帮助您克服最糟糕的情况-并且，您将很高兴使用一个框架，不会像WinForms那样阻碍您。

人们通常会说他们在WPF方面没有很好的经验，我通常会感到非常惊讶。我是一位从C ++ / MFC切换到C＃/ WinForms到C＃/ WPF的开发人员。从WinForms到WPF的过渡并不容易，因为学习XAML并不是一件容易的事，但是一旦掌握了它，它就是一项了不起的技术。我，一个，不能回到WinForms。WPF太棒了。

令我困扰的另一件事是人们通常如何将WPF与仅UI关联。我认为在UI设计方面，它确实比WinForms好100倍，但是您还有很多其他原因会喜欢使用WPF：

1. UI，当然。
2. 绑定。只是简单的魔术。UI之后最强大的功能。LOB应用程序从中受益最大。
3. 命令。
4. 关注点分离。设计师从事设计工作，程序员编程。
5. 附加属性。您可以在不使用源代码的情况下扩展第三方控件的功能（尽管这很可能是第一点的一部分）。
6. 轻松过渡到Silverlight（网络和WP7）

关于最后一点，您可能不同意我的看法，这是您学习WPF的原因，但是如果您问我，那是最大的问题之一。学习WPF后，可以轻松过渡到Silverlight。Silverlight越来越大，它也是一项了不起的技术。

最大的原因是，这就是未来。可以将它与Silverlight合并，但是技能将保持不变。

因此，我强烈建议您采用WPF方式。

显然，WPF是未来的思考方式。掌握它很困难，但是该平台具有很好的架构和灵活性。

几行建议：

• 轻松上手：不要尝试仅使用MVVM或精美的动画来实现您的第一个项目。从窗口，按钮和列表开始。
• 利用DataBinding。
• 购买Adam Nathan 所著的《WPF Unleashed》。

首先，我应该主要是asp.net开发人员，尽管我以前使用过很多winforms。一周左右（40多个小时）后，切换到WPF并没有达到您设定的（imo）水平，大多数情况还是第二天。

无论如何，至少在本书出版商看来，我相信Anders Hejlsberg是WPF背后的建筑师之一。

“ 作为WPF背后的建筑师之一，克里斯·安德森（Chris Anderson）熟练地不仅解释了“方法”，而且解释了“原因”。对于任何想了解WPF的设计原理和最佳实践的人来说，这本书都是极好的资源。” – Microsoft公司技术研究员Anders Hejlsberg

http://www.amazon.com/Essential-Windows-Presentation-Foundation-WPF/dp/0321374479

Winforms与Delphi开发几乎相同。当然，这是有原因的。正如Delphi / Object Pascal对象模型严重影响C＃一样，表单系统也影响Winforms。

WPF似乎是事情发展的方向。有人说，（华丽的！）VS2010 UI是基于WPF的，这与以前基于Winforms建立的版本不同。

如果要保持舒适，请使用winforms。如果您想了解最新的最新信息，请沉浸在WPF中。

我不是Delphi程序员，但是是的，我同时从事WinForm（繁重）和WPF（中等程度）的工作。我在某种程度上同意您的挫败感，因为有人要从WinForm切换到WPF，因为我自己处于那种情况，但是直到我习惯了。了解并了解WPF与WinForm相比多么精彩和灵活。它具有繁重的学习曲线，至少对于那些有Delphi背景而不是Winform的人而言。对于您来说，向WPF而不是WinForm绝对值得，而且值得花时间。

您可能需要查看以下链接以开头：

• http://drwpf.com/blog/
• http://www.wpftutorial.net/
• http://joshsmithonwpf.wordpress.com/

我已经完成了一些Windows窗体工作（大多数是在Pocket PC上），以及其他一些使用相同原理的非.NET环境。大约三年前我搬到WPF时，头几个月我一直在发誓。最终，它只是被“单击”，而我没有回头-实际上，如果我的下一个项目要求我回到Windows Forms，我会感到很沮丧。

Windows窗体的上一次更新是在2005年（VS 2005）。它仍然存在，但不再被Microsoft改进。WPF是桌面应用程序的新手，因此，如果您要使用MS工具迁移到.NET平台，那我肯定是安全的选择。有人将Silverlight用作桌面解决方案，但是当我将其视为一种可能性时，我发现它有太多限制（在Web上下文中可能有意义，但在桌面上则没有太多限制）。

底线：学习曲线很陡，我仍在学习。但这一切都值得。其乐无穷。

如果要从头开始编写新的应用程序，则使用WinForms是一个错误。从投资的角度来看，它基本上已经死了。Microsoft将保留它很长一段时间，但是您将不会获得任何新功能或新支持等。WPF是MS平台上未来桌面应用程序的明确方向。

从职业角度来看，了解WPF与WinForms也要好得多。由于上述相同原因。此外，您还将学习Silverlight。这两个平台之间存在大量重叠。

最后，WPF更有趣。而且功能更强大。

学习曲线更加陡峭，我给你。但这最终更有意义。

应该提到的另外一个考虑因素是，没有计划在mono中支持WPF。我知道您对（单）跨平台支持没有任何兴趣，但是将来（如果您使用Winforms）可能会有这种机会。大概会以单声道（或类似形式）支持WPF。

编辑：正如我提供的链接所指出的那样，并且Gulshan的评论突出了，Moonlight是由Mono团队领导的开源工作，旨在提供跨平台Silverlight支持。

当我听到有关WPF的消息时，我感到非常兴奋，这个想法听起来很棒，而且我所看到的一切都非常美好。但是，当我在Visual Studio 2008中使用它（公认的是一个beta）时，我发现在设计器/ IDE中使用它令人沮丧且古怪。

我当时在自己的博客上发布了一些信息：
http : //blog.dantup.com/2007/08/visual-studio-2008-beta-2-first.html
http://blog.dantup.com/2007 /08/wpf-designer-cider-part-2.html

我在2010年还没有尝试过，尽管我已经和一些有经验的人进行过交谈，而且听起来好像还有些复杂/烦人。

我认为您的应用程序无疑在WPF中看起来/感觉会更好，但是我也认为这将花费您更长的构建时间，并且您将一路狂奔。