Windows 窗体是旧技术吗? [英] Are Windows Forms old tech?
问题描述
是时候为我的项目编写GUI了，我想知道使用什么技术.我在 .NET 1 & 中进行了大部分 .NET GUI 开发.2，所以我很了解Windows Forms.我隐约知道 WPF，但还没有尝试进入它".
Windows 窗体是死了还是死了?WPF 是一项值得学习的好技术吗?它是未来，只是一个阶段，还是可以与 Windows 窗体并驾齐驱的技术?
此外，任何经验都会很高兴听到，特别是来自广泛使用这两种方法的人的经验.您如何发现在两个框架中实现了类似的功能?
WinForms 是死了还是死了?
没有.它没有得到显着的进一步开发(即没有新的主要添加)，但它在 .NET 4 中得到了全面支持，例如.
<块引用>WPF 是一项值得学习的好技术吗?
是的.
<块引用>它是未来，只是一个阶段，还是可以与 WinForms 携手并进的技术?
您最终会转移到 WPF，但也可以理解，有大量的现有代码库是用 WinForms 编写的，并且没有使用 WPF 重写它们的商业案例.因此仍然支持 WinForms.
<块引用>此外，任何经验都会很高兴听到，尤其是来自广泛使用这两者的人的经验.您如何发现在两个框架中实现了类似的功能?
从广义上讲，WPF 更具表现力.如果您将框架视为可以以各种方式组合在一起的一组乐高积木，那么 WinForms 积木要大得多 - 每个积木都做了很多 - 因此将它们组合在一起的方法更少.很多时候，当你需要一些东西，但又不像现有的积木那样，你必须从头开始编写自己的.在 WPF 中，积木明显更小，并且可以以许多有趣甚至令人惊讶的方式进行组合.
举一个具体的例子，考虑一下 WPF Button 如何成为一个可以托管任意内容的容器 - 不仅仅是 WinForms 中的图像+文本，而且绝对是任何其他 WPF 控件或控件集.
与 WinForms 相比，WPF 也更容易编写动态布局.后者也有布局，但问题是它们是视觉设计器中的皇家 PITA，并且通过代码编写 WinForms 组件初始化非常繁琐.使用 WPF，您只需手动编写 XAML 标记，并且布局(以及一般的控件树)在 XML 中非常自然地表示.
部分源于上述，我发现 WPF 更容易本地化.一方面，这是因为您确实需要动态布局以实现本地化(因为您事先不知道所有语言环境中字符串的长度).WinForms 对此的解决方案不仅要考虑文本标签，还要考虑控制位置和大小，作为可本地化的属性"——因此，如果翻译人员发现字符串不合适，他应该自己重新排列表单上的控件.在 WPF 中，动态布局是默认方法，因此本地化程序只处理字符串.
WPF 绑定框架相当强大(即使冗长，由于缺少内联转换器)，并且大力促进 MVP，并且一般来说，模型/视图分离.这可以通过 2.0+ 中的 WinForms 实现，我也在那里尝试这样做，但它更乏味，尤其是在 null 处理方面，有时可能是 相当错误.
一个特别的痛点是 WinForms 设计器与源代码管理交互的方式.这里有两个类似的问题.首先，设计器将编辑后的表单序列化为代码，有时布局中非常小的变化会使设计器生成完全不同的代码(如果您编辑工具栏，这一点尤其明显)，因为它会打乱代码行——即实际上它改变了一个一行上的单个属性值，但它也重新排序了所有内容.这会导致历史上的很多杂音(在查看差异时几乎无法判断到底发生了什么变化)，但更重要的是，这意味着合并此类文件是一个令人头疼的问题.这通常发生在两个人同时使用相同的表单时，然后一个提交他的更改，另一个尝试提交，发现文件在此期间被更改，尝试合并，查看差异，并跳出最近的窗口.
当您使用 WinForms 可本地化表单时，会发生非常相似的问题，它将某些属性推送到资源文件.同样，设计者非常喜欢对资源文件中的属性值重新排序以进行任何微不足道的更改，所有问题都与前面描述的相同.
现在说说 WPF 的不足之处.一个主要的问题是它有点复杂，对于只熟悉 WinForms、VCL、VB 或其他类似传统"框架的人来说可能会觉得不熟悉.另一个问题是，在我看来，文档并不完美——它通常提供了一个不错的概述，但很少涵盖极端情况，其中一些可能非常重要.WinForms 也是这种情况，但可能的组合较少，因此也较少出现极端情况.
还有第三方组件的问题.WinForms 已经存在很长时间了，有很多可用的，而且很多都非常成熟.WPF 相对年轻，仍在经历成长的痛苦，大多数第三方解决方案也是如此.
我在 WPF 中的一个特别讨厌的地方是它对文本进行抗锯齿的方式 - 大多数人认为与普通的 Windows ClearType 相比，这种方式的质量要差得多，尤其是在小字体上；有关详细信息，请参阅此错误报告.这在 WPF 4 中已修复，但尚未发布，即使发布，您也可能希望坚持使用久经考验的 3.5 SP1 一段时间；并且此修复程序未向后移植.
It is time to write the GUI for my project, and I am wondering what technology to use. I did most of my .NET GUI development in .NET 1 & 2, so I know Windows Forms reasonably well. I am vaguely aware of WPF, but not yet attempted to "get into it".
Are Windows Forms dead or dying? Is WPF a good technology to learn? Is it the future, just a phase, or a technology that can walk hand-in-hand alongside Windows Forms?
Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?
Are WinForms dead or dying?
No. It is not significantly developed further (i.e. no new major additions), but it is fully supported in .NET 4, for example.
Is WPF a good technology to learn?
Yes.
Is it the future, just a phase, or a technology that can walk hand-in-hand alongside WinForms?
It is intended that you eventually move over to WPF, but it is also understood that there are large existing codebases written in WinForms, and there's no business case for rewriting them in WPF. Hence WinForms remains supported.
Also, any experiences will be good to hear, especially from people who have used both extensively. How did you find implementing a similar feature in both frameworks?
Broadly speaking, WPF is much more expressive. If you look at frameworks as set of Lego bricks that can be put together in various ways, WinForms bricks are much larger - each one does a lot - and therefore there are fewer ways to put them all together. Quite often, when you need something-but-not-quite like what an existing brick does, you have to write your own from scratch. In WPF, the bricks are significantly smaller, and can be combined in many interesting and even surprising ways.
For a concrete example, consider how WPF Button is a container that can host arbitrary content - not just image+text as in WinForms, but absolutely any other WPF control or set of controls.
WPF is also much easier to write dynamic layouts in compared to WinForms. The latter has layouts, too, but the problem is that they're a royal PITA to work with in visual designer, and writing WinForms component initialization by code is very tedious. With WPF, you just write XAML markup by hand, and layouts (and control trees in general) are very naturally represented in XML.
Partially stemming from the above, I find that WPF is easier to localize. For one thing, it's because you really do need dynamic layouts for localizability (since you don't know in advance the length of the strings in all locales). WinForms solution to this is to consider not only text labels, but also control position and size, as "localizable property" - so the translator is supposed to rearrange controls on the form himself if he finds that strings don't fit. In WPF, dynamic layouts are the default approach, so localizer just deals with strings.
WPF binding framework is rather powerful (even if verbose, thanks to lack of inline converters), and heavily promotes MVP, and, in general, model/view separation. This is possible to achieve with WinForms in 2.0+, and I try to do that there as well, but it's more tedious, especially with respect to null handling, and sometimes can be rather buggy.
One particular pain point is the way WinForms designer interacts with source control. There are two similar problems here. First of all, designer serializes edited form as code, and sometimes very minor changes in layout can make the designer generate completely different code (this is particularly noticeable if you edit toolbars) because it shuffles the code lines around - i.e. in reality it changed a single property value on one line, but it also reordered everything. This leads to very much noise in history (it's nigh impossible to tell what exactly was changed when looking at diffs), but more importantly, it means that merging such files is a major headache. This usually happens when two people work with the same form at the same time, and then one commits his changes, and the other one tries to commit, finds out that the file was changed in the meantime, tries to merge, sees the diffs, and jumps out of the nearest window.
A very similar problem happens when you use WinForms localizable forms, which pushes some properties to a resource file. Again, the designer very much likes to reorder property values in resource file for any trivial change, with all the same problems as described earlier.
Now as to deficiencies in WPF. A major one is that it's quite a bit more complicated, and may feel unfamiliar to someone with experience only with WinForms, VCL, VB, or other similar "traditional" frameworks. Another problem is that documentation, in my opinion, is not perfect - it usually gives a decent overview, but rarely covers corner cases, some of which can be pretty important. This is the case for WinForms, too, but there are fewer possible combinations there, so fewer corner cases as well.
There's also the issue of third-party components. WinForms had been around for a long time now, and there are plenty of those available for it, and a lot of them are very mature. WPF is comparatively young and still going through growth pains, and so do most third-party solutions for it.
One particular pet peeve of mine in WPF is the way it antialiases text - which is perceived as being of much worse quality compared to plain Windows ClearType by most people, especially on small font sizes; see this bug report for more info. This is fixed in WPF 4, but that isn't released yet, and even when it will be, chances are that you'll want to stick with the tried and true 3.5 SP1 for some time; and the fix isn't backported.
这篇关于Windows 窗体是旧技术吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
