如何学好WPF
多年前的文章了，修改一下，以适应现期发展。
WPF，它的全名是Windows Presentation Foundation，是微软在.net3.0 WinFX中提出的。WPF是对Direct3D的托管封装，它的图形表现依赖于显卡。当然，作为一种更高层次的封装，对于硬件本身不支持的一些图形特效的硬实现，WPF提供了利用CPU进行计算的软实现，以用来简化开发人员的工作。
简单的介绍了一下WPF，这方面的资料网上也有很多。作于微软力推的技术，整个推行也符合微软一贯的风格——简单，易用，强大，外加一些创新概念的噱头。
多年前介绍的废话：
噱头一：声明式编程。从理论上讲，声名式变成不算什么创新。Web界面声明式开发已经很多了，这种界面层的声明式开发也是行业上的大势所趋。为了适应声明式编程的需要，微软推出了XAML，是一种扩展的XML语言，并且配套在.NET 3.0中引入了XAML的编译器和运行时解析器。XAML加上IDE强大的智能感知，确实大大提升了对界面的描述能力，这点是值得肯定的。
噱头二：紧接着微软又借着XAML描绘了一副更为美好的画面——界面设计者和代码开发者可以并行的工作，两者通过XAML进行交互，以实现设计和实现的分离。不得不说，这个想法是非常打动人心的。以往设计人员和开发人员的交互是一个痛点，两者多是通过设计人员利用photoshop编辑出来的图片进行交互的，需要开发人员根据生成的图片来进行程序上的转换，以生成实际可运行的程序。多了这么一层转换，出来的效果或多或少总会和设计人员的设计有偏差，所以，很多时候开发人员也不得不忍受设计人员的抱怨。WPF的出现，给了深陷苦恼的开发人员一线曙光——我只负责逻辑代码，UI交给设计师自己去搞，我们各行其事，通过工具组合就可以了。可实际开发中，这里又出现了问题，UI的XAML部分可以完全丢给设计人员么？
话题展开会有点长，微软提供了Expression Studio套装来支持用工具生成XAML。那么它是否好用呢？经过了一些配合，经常听到设计人员以及开发人员的抱怨：“这个没有Photoshop好用，会限制我的灵感”， “他们生成的XAML太糟糕了...”。确实，XAML沟通这个项目太理想化了，在同一项目中，设计人员使用Blend进行设计，开发人员用VS来开发代码逻辑，这个落地是有很大困难的：
· 有些UI效果是很难或者不可以用XAML来描述的，需要手动编写效果。
· 大多数设计人员很难接受面向对象思维，包括对资源（Resource）的复用也不甚理想。
· 用Blend生成的XAML代码并不高效，一种很简单的布局也可能被翻译成非常冗长难读的XAML。经历了很多不愉快之后，很多公司引入了一个integrator的概念。专门抽出一个较有经验的开发，负责把设计人员提供的XAML代码整理成符合要求的XAML（没有什么是在中间增加一个层次不能解决的）。并且在设计人员无法实现XAML的情况下，根据设计人员的需要来编写XAML或者手动编写代码。关于这方面较好的建议是：设计人员放弃Blend，使用Expression Design。Expression Design工具还是较复合设计惹怒眼的，除了要注意些像素对齐的问题外，这样的输出结果，开发人员是比较容易转化的。可使用Blend打开工程，再从Expression里复制粘贴，其粘贴是可以格式化到剪切板的——可在design文件中选中某一个图形，复制，并切到blend对应的父节点下点粘贴，适当进行后续地修改。
作为矢量化的图形工具，Expression Studio确实提供了很多便利，也部分达到了设计人员同开发人员协同合作，只是不像微软描述的那样自然。总体来说，还可以落地。
后面，要步入本篇文章的重点，也是很多时候听起来无奈的事情——微软在宣传WPF的时候，过分宣传XAML和配套工具的简易性，这样偏向造成了很多刚接触WPF的人的一种误解：WPF=XAML? 哦，又是类似HTML的玩意...
这是不太对的，作为一款新的图形引擎，微软以Foundation作后缀，代表了它的野心。寄希望于托管平台的支持，WPF期望打破长久以来桌面开发与Web开发的壁垒。当然，由于需要.net3.0+版本支持，配套的XBAP已经逐渐被Silverlight所取替。确实在WPF的设计之中，XAML（Markup）算是它的亮点，XAML也吸取到了Web开发的精华。对于帮助UI和实现的分离，XAML如虎添翼。但XAML并不是WPF所独有的，WF等其他技术也使用了XAML；XAML只是个语法糖，帮助更舒服地编写UI，如果开发人员愿意的话，在WPF中可以一行XAML都不写，完全使用手撸后台代码的方式来实现所有的UI。正是为了说明这样观念，Petzold在他的书《Application = codes + markup》将内容一分为二，前一半完全使用代码来实现的，后面才讲了XAML在UI上的应用。当然，这样“逆势”的书叫好不叫座，如果有一定WPF开发经验了，回头来看发现其组织书籍的方式非常经典，但如果带着“简单UI”的成见来看，抱着这样的书入门就会一头雾水了。
所以很多朋友抱怨，WPF学习曲线太曲折，它的上手很容易，深入一些就很困难，经常出现一些莫名其妙的问题，不查看源代码都不知道如何解决。这个复杂是由数量级决定的，借一下LearnWPF的数据，来对比一下Asp.net, WinForm和WPF 量比：
|
ASP.NET 2.0 |
WinForms 2.0 |
WPF |
|
|
|
|
|
1098 public types 1551 classes |
777 public types 1500 classes |
1577 public types 3592 classes |
要搞定这么个大家伙，先要撸到它的脉络——庖丁解牛，要知道在哪下刀。先聊一下如何学门新技术。
一门新技术，对大多人来说说，往往是通过看相关书籍入门的，边看书边撸hello world是最常见的方法。一个知识树：
学习是一个不断丰富知识树的过程，一方面添枝加叶（向外）、另一方面不停重构演进（向内）——所谓至大无外，至小无内。
一门新技术，就像一个new出来的对象，在了解其轮廓之前，它是游离在知识树外面的，需要找到新老知识之间连结的关键。
对于WPF来说，入门首选MSDN，微软做的已经够好了，Sample带的也不错。再往下，比如Sams.Windows.Presentation.Foundation.Unleashed或者Apress_Pro_WPF_Windows_Presentation_Foundation_in_NET_3_0也不错。
接下来学些什么？要找一个插入点，期望其“以点破面”、通过它可以凿开ＷＰＦ的大门，把真东西露出来。这个推荐Dependency Property(DP)。ＷＰＦ的命门在ＤＰ上，从它入手最好不过了。
ＤＰ，也叫依赖属性，从名字来看，它首先是一个属性，依赖是一个形容词。就是在传统的属性上加了个“依赖”。
找一个ＤＰ，它长这副模样：
public static readonly DependencyProperty IsSpinningProperty = DependencyProperty.Register("IsSpinning", typeof(bool));
public bool IsSpinning
{
get { return (bool)GetValue(IsSpinningProperty); }
set { SetValue(IsSpinningProperty, value); }
}
单看IsSpinning，外表长得和属性一样，除了get/set里面“一大坨”代码。看看这“一坨代码”也知道，就是在“存取”的实现上下文章了。
其实就是个“二房东”的模式，对外面看好像“是我的”，内部就不一定是“咋回事”了。
是咋回事呢？属性的值存在哪了呢？
存在“共享XX上了”，如果属性值不变，就用静态方式存在全局——大家共用一份；如果改变了，就在DependencyObject内部弄个Dictionary<string,object>，将变化的值保存在自己这儿。
细一点说，每个DependencyObject内部搞了个EffectiveValueEntry的数组，EffectiveValueEntry是个结构，封装了很多状态值animatedValue(动画)，baseValue(原始值)，coercedValue(强制值)，expressionValue(表达式值)，这些值对应不同的场景。
关于ＤＰ的实现，可以参照：一站式WPF--依赖属性（DependencyProperty）一 - 周永恒 - 博客园 (cnblogs.com) ，这里不再赘述了。
随着依赖属性的引入，又带来了设计上的一个新模式：MVVM（Mode-View-ViewModel）。它长这个模样：
public class NameObject : INotifyPropertyChanged
{
private string _name = "name1";
public string Name
{
get
{
return _name;
}
set
{
_name = value;
NotifyPropertyChanged("Name");
}
}
private void NotifyPropertyChanged(string name)
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(name));
}
}
public event PropertyChangedEventHandler
PropertyChanged;
}
public class NameObjectViewModel : INotifyPropertyChanged
{
private readonly NameObject _model;
public NameObjectViewModel(NameObject
model)
{
_model = model;
_model.PropertyChanged += new PropertyChangedEventHandler(_model_PropertyChanged);
}
void _model_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
NotifyPropertyChanged(e.PropertyName);
}
public ICommand ChangeNameCommand
{
get
{
return new RelayCommand(
new Action<object>((obj) =>
{
Name = "name2";
}),
new Predicate<object>((obj) =>
{
return true;
}));
}
}
public string Name
{
get
{
return _model.Name;
}
set
{
_model.Name = value;
}
}
private void NotifyPropertyChanged(string name)
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(name));
}
}
public event PropertyChangedEventHandler
PropertyChanged;
}
public class RelayCommand : ICommand
{
readonly Action<object> _execute;
readonly Predicate<object> _canExecute;
public RelayCommand(Action<object> execute, Predicate<object> canExecute)
{
_execute = execute;
_canExecute = canExecute;
}
public bool CanExecute(object parameter)
{
return _canExecute == null ? true : _canExecute(parameter);
}
public event EventHandler CanExecuteChanged
{
add {
CommandManager.RequerySuggested += value; }
remove {
CommandManager.RequerySuggested -= value; }
}
public void Execute(object parameter)
{
_execute(parameter);
}
}
public partial class Window1 : Window
{
public Window1()
{
InitializeComponent();
this.DataContext = new NameObjectViewModel(new NameObject());
}
}
<Window x:Class="WpfApplication7.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1" Height="300" Width="300">
<Grid>
<TextBlock Margin="29,45,129,0" Name="textBlock1" Height="21" VerticalAlignment="Top"
Text="{Binding Path=Name}"/>
<Button Height="23" Margin="76,0,128,46" Name="button1" VerticalAlignment="Bottom"
Command="{Binding Path=ChangeNameCommand}">Rename</Button>
</Grid>
</Window
类的关系如图所示：
ViewModel，顾名思义，就是View＋Model，是两者的“杂交”，是那片“三不管”的灰色地带。
从名字来看，View和Model都很纯，一个是ＵＩ、一个是数据，世上的事往往是没那么单纯的。取得了数据之后，往往要加点“私货”再传给ＵＩ。这份脏活原来是Controller干的，现在扔在了ViewModel中。
Controller就像个“销售”一样，原来是直接对应外部需求（View）,同时指导内部的工兵干活（Model）。后来发现他太不可控了，为了点销售业绩，啥活都接。
能不能换个模式？
把客户的需求抽象出来，定好个全集，内部对应一份，然后根据不同的需求“适配”给不同客户。这就是ViewModel的由来，将客户(View)的需求抽象成Property、Command等，针对它实现需求，然后用WPF自带的绑定、Command等模式将这个映射“落地”。
说白了，MVVM代表了一种思想，叫做Meta-Control（元控）——通过元数据来控制View，在Model与View之间引入了一层抽象。相对来说，数据结构+算法的思路更像是“数控”。
DP带来了很多东西，依靠它的支撑，WPF搞出了一系列名词：逻辑树、视觉树，路由事件，Style和Template等等。
那么如何学好ＷＰＦ呢？
1. 熟悉XAML，熟悉布局，熟悉基本控件，能够根据产品端提出的原型画出界面。——（入门）
2. 研究事件、Style、Template，提升自己的项目能力。——（可按Winform风格实现WPF）。
3. 熟悉MVVM，熟悉ICommand，学会使用MVVM框架实现程序。——（进入WPF味道）
4. 研究依赖属性、路由事件，学会写自定义控件。
5. 学会换肤，可以更新整个界面的样式（Light/Dark）；学会一个ViewModel对应多个View。（学会写机制）
6. 接触开源框架MVVM Light等，研究其精髓，提升WPF掌控能力。
7. 提升对WPF技术点的取舍能力，向Presentation的本质深入。
祝大家WPF之旅一帆风顺。
作者：周永恒
出处：http://www.cnblogs.com/Zhouyongh
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
