使用 Windows 窗体技能对 Silverlight/WPF 进行编程答案

【问题标题】：Programming Silverlight/WPF with Windows Forms skills使用 Windows 窗体技能对 Silverlight/WPF 进行编程
【发布时间】：2011-05-24 14:03:00
【问题描述】：

一个人可以在多大程度上使用 Windows 窗体技能编写 Silverlight/WPF？

在多大程度上可以开发类似于 Windows 窗体的内部应用程序？

我的问题的背景是我申请需要 Silverlight 的职位，我试图争辩说我的 Windows 窗体经验应该足以应付内部应用程序。

我知道 Silverlight/WPF 提供了更多功能，但主要是针对类似网络的“花哨”内容，以及通过 MVVM 模式提供更高 SoC 的可能性。

【问题讨论】：

是的，但您的竞争对手实际上知道 Silverlight。因此，他们几乎肯定会在获得这份工作方面拥有巨大的优势。如果您想使用 Silverlight，我强烈建议您开始学习 Silverlight（或 WPF，等等）。
@Matt 不仅是竞争对手，还有同事。除非每个项目都是单独的，否则如果您使用类似的知识库，与他人合作会容易得多。
@Matt - 我认为大多数 .NET 开发人员都使用 ASP.NET，而不是 Windows Forms/WPF/Silverlight？

标签： .net wpf winforms silverlight mvvm

【解决方案1】：

是的，您绝对可以开始从事 WPF/SL 工作，您的 WinForms 经验会有所帮助，但我不同意这样就足够了。

有趣的是，目前在 WPF 中工作的大多数开发人员基本上都来自 WinForms 背景（根据我的经验），他们中的大多数人认为 WPF 与 WinForms 没有太大区别，他们尝试开发 WPF 应用程序应用相同的问题解决技术、概念和方法；这就是所有问题的开始。

我建议您首先阅读 WPF/SL 书籍（至少前半部分），然后在您处理 WPF/SL 应用程序时尝试使用新概念（XAML 、Binding、Commands、DependencyProperty、Styles、Triggers 等）来解决您遇到的每一个问题（即使您可以轻松地以旧方式解决/实施它）。

有些人可能不同意这一点，但我看到我的朋友用 WinForms 方式实现了几乎所有东西（在 WPF 中），后来抱怨内存泄漏、性能等。

【讨论】：

我同意 ... 对于 SL，我推荐 silverlight 4 unleashed ... 这在很多方面改变了我的编码方式
在我看来，如果你这样做（尝试以纯 MVVM 的方式解决所有问题），你会获得很多很好的经验，但最终会得出结论，做 everything i> 在纯 MVVM 风格中，麻烦多于其价值。 MVVM 是解决某一类问题的一个很好的解决方案；对于其他人来说，它也是一个非常好的反模式，主要是由于非常实用的原因，MS 工具集仍然有很多不足之处。但是遵循这个建议会让你很好地了解 MVVM 在哪里工作以及在哪里不工作，即使它会使你的第一个项目非常非常慢。
@Ken - 我同意你关于 MVVM 的看法；例如，如果您正在创建自定义控件 MVVM 通常不是首选/使用。我不确定你是否觉得我在吹嘘使用 MVVM，但事实上我在回答中根本没有建议 MVVM，MVVM 是 WPF/SL 应用程序的一个很好的模式，但对于来自 WinForms 背景的人来说这不是学习/专业知识的第一件事。
我想我的回答让 MVVM 意义重大。你是对的，有很多 WPF/SL 特定的东西并没有真正将 MVVM 作为一种模式。不管怎样，我自己的经验让我相信 XAML 的做事方式现在被夸大了。以 XAML 方式做事可以解决特定类别的问题，但会引入一大堆新问题。经典示例：我刚刚重构了一个大型项目。 VS 非常清楚地告诉我所有问题在我的 C# 代码中的位置，但让我对 XAML 中的数据绑定问题完全视而不见。唉。

【解决方案2】：

如果我正在为一个项目配备人员，并且有人跟我争辩说他会成为一名优秀的 WPF 开发人员，因为他拥有丰富的 WinForms 经验，那么他得到回电的几率很低。 特别是，如果他谈到 WPF 提供的内容“主要以类似网络的方式提供'花哨'的东西。”

这告诉我的是，“我已经阅读了你正在使用的这项技术，但我没有使用它的经验，但这并不妨碍我形成关于你将不得不改变的观点。”

【讨论】：

我正在考虑包含大量 CRUD 的小型内部项目，这些项目不一定要好看。我不知道我看到的广告是不是针对那种项目的。
嗯，你看，你再次认为 WPF 的重点是它如何使事情看起来。你的评论只会强化我的感觉，即你的态度会给我的项目带来麻烦。 WPF 的重点在于它使 UI 应用程序的体系结构合理化。它消除了 WinForms 模式和实践对世界造成的巨大损害。这是有趣的东西，如果你愿意学习的话。迈向开放的第一步是承认你不知道的东西。

【解决方案3】：

我想说的是，独立开发应用程序与作为完全熟悉 Silverlight/WPF 的团队的一员工作之间存在很大差异。确实，您可以通过拖放设计 UI，使用可视化设计器分配属性，然后在基于 XAML 的框架中编写您需要的所有代码，并且几乎不会注意到它与您使用的 Winforms 体验之间的差异到。与熟悉 WPF/Silverlight 世界中已成为标准的所有概念和模式的其他人合作的过程无疑会有所不同：绑定、命令、样式、依赖属性等。如果您的工作需要要与他们的集成，如果忽略两个平台的差异，您将遇到问题。

这并不意味着 Winforms 体验毫无用处。所有的逻辑仍然存在，所有相同的服务器端代码仍然需要编写，并且可能还有六个其他地方你正在使用的 UI 类型至少无关紧要。了解 Silverlight 或 WPF 的最佳方式可能是拥有一个真正的项目，您可以轻松地使一些新想法与您习惯的一些相同逻辑一起工作。

很多问题都归结为程序员的素质，无论您有什么经验。当然，如果我想要有人维护现有的 WPF 应用程序，我会想要一个有这种经验的程序员，但如果我想要的话，我很乐意找一个写好的 Winforms 代码并且愿意学习新范例的人开发新的应用程序或组建一个全新的团队。

在大多数需要 Silverlight/WPF 程序员的情况下，认为 Winforms 体验“足够好”是错误的，就像我需要有经验的 C# 时，C++ 体验不够“好”一样程序员。 在概念上有足够的差异，您至少需要表现出进行范式转变的意愿，并且可能对新技术的核心概念有一定的了解。也就是说，好的代码就是好的代码，我认为任何人都不应该因为缺乏对特定技术的经验而被解雇。

【讨论】：

【解决方案4】：

我想说，如果您拥有丰富的 WinForms 经验，您应该能够相当轻松地迁移到 SL/WPF；不过，如果您至少对 XAML、依赖属性和这些平台的其他特性有基本的了解，我不会说您目前能够开发 SL/WPF 应用程序。

我建议您查看 Pete Brown 的帖子“10 things Beginning Silverlight and WPF Developers Need to Know”，了解从哪里开始的一些想法。我还推荐他的书Silverlight 4 in Action，从头开始真正培养这些技能。

【讨论】：

【解决方案5】：

您的第一个 wpf 应用程序不可避免地会像一个 winforms 应用程序。就我而言，这样做是可以的。但是如果有人发现你在不使用 MVVM 的情况下制作了一个 30 对话应用程序，他们会杀了你 :)
在任何情况下......你有你的第一个 WPF 项目要完成......你最终可能会像它的 winforms 一样进行编码（代码背后的代码很重）。

【讨论】：

我同意 Basarat 的观点，“你可能最终会像它的 winforms 一样编码”，但请发誓不要这样做，只有你才能理解 WPF 的真正力量并利用它。