经常有小伙伴给我的视频留言问这类问题：WPF值得学吗？WPF市场怎么样？

不仅仅是学习编程，其实学习任何东西的时候，我们都必须知道问哪些正确的问题才能帮助我们学习。“WPF值得学吗？”这个问题并不是学习WPF的时候应该问的，应该问的问题是“我们在学习WPF的时候，到底在学习它的什么？”

所以“WPF值得学吗？”这个问题的答案，完全取决于你是怎么看待学WPF这件事情的。你是想学一些语法的使用，埋头只要接受别人的设计思路然后机械地把它通过敲代码翻译成一个产品；还是说你想要做一个设计者，想要做出和别人不一样的，一眼看上去就很惊艳，对市场来说有价值的产品出来。如果答案是前者，那么我认为不值得学，市场上有比WPF需求量大得多的框架可以学习。如果是后者，我会说，WPF是一个不错的起点。

首先，对于我来说，接触WPF完全是因为它在我工作环境里面需要用到数据可视化的地方有着比WinForm更好的表现，出于优化的心态我从WinForm学习了WPF。很快我就开始学习Web技术，并且发现WPF的架构整体（特别是使用MVVM模式的项目）和Web非常接近。区别在于WPF是利用.net框架渲染出来的而Web则是利用浏览器。

WPF是一个框架，一种设计概念。我们学习C#编程，想要创造GUI的界面让用户和我们的业务逻辑产生交互，那么可以选择使用WPF。它本身结合 Visual Studio 提供的设计器，为我们提供了一种相对简单、智能的 GUI 界面设计的方法。

如果小伙伴疑惑的是，我学习了WPF好不好找工作，这个东西有什么作用，这样的具体问题的话，我不能未卜先知，给出一个纵观整个编程市场的靠谱的建议，这个大家可以自己去招聘网站上体会一下市场需求，而且还有一点是，需求一直在变化的。如果一个小伙伴看到市场前景不错然后去学习了WPF，结果等几个月之后发现没有那么多的需求了，那就很尴尬了。

其实这里我们不妨换一个思路：我们在学习WPF的时候到底是在学习什么？是在学习它的语法？还是学习它的框架构造？是学习怎么做一个具体的GUI界面？还是在学习GUI与背后的业务逻辑交互的方式？

其实如果往理想的状态来看，如果有一些用户他希望完成某种业务逻辑，其实用户是不关心具体这个东西是”用什么框架实现的“的。市场上有这么多可以制作桌面GUI的语言、框架。甚至魔改的WinForm在表现上也不会逊于WPF。

在选择框架上纠结，就好像在选择电子游戏的时候，非常在意它是用什么引擎开发的，而不是游戏的质量本身（比如游戏性、画面、世界物理等）。一款2015年的3A大作，使用虚幻3引擎开发，难道表现力一定逊色与一款2020年用虚幻4开发的游戏吗？其实事实上，经过专业开发团队魔改的虚幻3引擎可以做到白板虚幻4做不到的效果，所以拿着框架去评判开发水平是一件没有意义的事情。

既然用户不关心你是用什么框架去实现的，他们想要的其实就是一个好用的软件，它有一个界面，然后可以通过背后的业务逻辑实现他们的某种需求，没有bug、使用方便，仅此而已。这个问题其实有一个很好的例子：卖自行车锁的商家卖的究竟是什么？是一块钢材料做成的锁具？还是用户所需要的安全感？这个问题延伸出来的意义在于，自行车锁的商家的战略思路会产生变化：我的最主要的竞争对手到底是使用更坚固合金其他车锁厂，还是可以验证用户信息存车取车的智能自行车车库？

按照这个思路，我们在选择哪个框架进行学习的问题上，就可以有正确的思考了。用户究竟是不是对他使用的软件产品有具体的框架需求？比如他们是不是非 WPF 的不用？非 Java Swing 的不用？还是说只要能满足他们的需求，无论是什么东西做出来的，他们都会满意？

这也就带出了我想要说的另外一个问题：桌面应用开发的大趋势，其实是越来越颓废的。

网络应用、云计算、PaaS、SaaS、微信小程序，浏览器功能的日益强大，使得桌面应用开发的需求逐年下降。如果说一个用户只是想实现界面简单的功能和操作，对高消耗的视觉化呈现需求很小的时候，为什么要用桌面应用开发呢？这样就让桌面应用开发越来越走向了只能在非常特殊需求的地方被使用的趋势。比如，现在很多最新版企业级的分布式应用，都是桌面版和web版共存的状态，

基于网络的应用，在更新、发布、使用等方面相比传统桌面应用更加优越。比如说，我现在有一个文本编辑器。它更新了。我在用它的时候会怎么样呢？它会有一个弹窗告诉我有更新了，然后展示了更新内容，然后让我去下载它。那么假设以后这种东西都是云端呢？比如Google 的 Docs 服务（网络基础）对比微软的 Office Word（桌面基础）？很明显我不需要在它有更新的时候去选择下载那么麻烦，我主动登陆对方的网站，获取该应用，直接所使用的就是最新版，网页里它会展示给我一个交互界面，然后高开销的处理和储存都是在云端的，本地前端负责处理低开销的任务，比如UI展示、用户互动之类的。

这里补充一下，微软的 Office 套件也有网络基础的版本。也是印证了我的观点。同样的业务逻辑放在服务提供者的中心发布服务器上，也可以使用。当然基于目前的技术限制，还远远达不到桌面版的100%性能和效果，很多功能也受限制。这里只是说一下未来的趋势。

细化到我们开发架构的选择，那么就是要考虑把业务逻辑放到本地的局限性。更新、维护、防止盗版等都是需要解决的问题，而云端恰好原生态就解决了这些问题。所以随着云技术的发展，这个趋势也是不可阻挡的。越来越少的企业会只专注于单纯的桌面应用开发，即使有桌面应用，也会注重和web的交互。但是这样的关系又显得非常暧昧，如果你既有的很多服务都依赖于网络，在需求不冲突的情况下，那么为什么不干脆就直接把包括UI在内的全部内容搬到网络上呢？

拿一个场景来说：比如一个客户想要处理一些数据，我们给他写了一个WPF应用。我们需要把安装包发给他，他要安装，然后会遇到实际环境的一些兼容性问题；我们再去调整；然后再把新版本的安装包给他；客户进行了升级，然后再用，就好用了。过了一段时间，用户说我需要加一点新的功能，所以我们又给他开发了新的功能，把安装包发给他了，他升级，再用……

如果我们直接提供网络应用呢？这所有的来来回回安装包的发布、更新、调试、调整、兼容性问题就都没有了，给用户一个网址，浏览器一进去就看到了我们的界面，然后用就可以了；用得不顺利了，告诉我们，我们直接在自己的服务器上调整了就好了。下次用户登录的时候，以前的问题已经解决了。这个转变既简化了用户获取该应用的步骤，也简化了服务提供者对服务进行升级和维护的步骤。

所以结论是，未来的应用开发的市场，一定是网页基础的应用占大头，然后才是桌面应用去填补那些需求空缺。

看到这里，小伙伴肯定要问了：那就是说现在学习WPF是白费功夫了？

其实看问题不能这么局限。选择学习哪个框架一直是新手选择困难症的爆发点。很多小伙伴学一个框架刚刚入门，看到另外一个框架很热门，就放弃了原来的学习，去学习那个框架了；然后热度过了又去学习其他的热门框架了……搞了半天变成了一个循环：不停地在社交媒体求证哪个框架好用、市场销路广，然后每个浅尝则止地学两下，搞了半天什么都会一点，什么都成不了体系。

WPF也好，vc++也好，python也好，Java Swing也好、Electron也好……无论学哪个，只要一个人肯定下心钻进去，把整个体系搞透，都会触及到软件框架设计这个知识点。比如我们学习WPF，我们其实在学它的具体语法的同时，也在学习一个GUI用户界面是怎么处理用户的输入与背后业务逻辑是如何交互的。我们让UI接受用户的输入、然后传递到业务逻辑、然后进行数据的处理、收集、储存、运算，然后用某种形式反馈给用户。这些步骤里面的各个部件是怎么交互作用，相辅相成的我们必须要体会到。如果学成了体系，那么我们在设计一个软件的时候就会脱离具体语言或者框架的限制，而是根据用户需求、我们自己的设计需求、各种框架的优缺点进行选择。在这个水平层，“一门具体的语言”就可以被看作“某种语法”，“框架”就可以被看作“具体实现手段”，从零基础到能搞出自己的小项目来，学习成本和难度也就将低了。而不用像学第一个框架一样巨细无遗地去从最琐碎的细节开始学起。

其实以WPF为代表的设计框架，真正难学的是它的架构逻辑，而不是具体的语法。如果一个语法一时间忘记了，到官网上看几分钟很容易就可以刷新自己的印象然后用出来。这是没有太多难度的。但是想要消化它的框架就必须要很长时间的磨练。说白了就是“我不知道学习这个框架的具体的问题在哪里？它又是如何提供具体的特征去解决的？”当学好了第一个框架之后，这个问题就得到了很好的解决。那么之后的学习也顺滑了。

比如我们学习 WPF 的 MVVM 模式，一开始可能觉得没有什么意义。但是本质上，MVVM将UI交互层的代码和逻辑层的代码进行了归类和细化，让我们可以在一个地方去系统化地精打细磨我们设计的软件。比如我们可以专注 View 去做一个更加好看、互动、灵巧的界面；或者专注于 Model 去设计一些提高我们算法性能的对象，专注 ViewModel 去设计更加巧妙，性能更高、Bug更少的业务逻辑。如果不是一个人开发，而是一个团队的话，这个模式就可以让团队有更加专业性的人员负责不同的部件，并且最终可以顺利地组合在一起，形成一个完整、系统的软件产品。

学会了这个模式，在学习其他架构的时候，也可以找到类似的设计模式，并且理解它们为什么会有这些特征，这些特征是干什么的。

如果小伙伴可以通过WPF入门，以“了解整体框架”为目的去学习，那么就可以触类旁通。倘若未来想要学习另外一个框架（比如Electron）就不会拘泥于那些语法细节。你在学习的时候会本能地去寻找这个框架里为了实现某种通用功能所提供给开发者的特征，无论是深度和广度都会远远高于第一次学习任何框架的人。