WPF学习感受

WPF是微软推出的一个先进的界面类库，具有高度的可定制性，吸收了很多html的思想，打破了传统的假面编程思路，很有创造力。
尤其是当WPF采用了XAML作为界面描述语言之后，更加简化了WPF编程的难度，专门设计的Visual studio编程IDE对于WPF的支持更是无以复加，称得上是绝配。
但是，学习了这么久的WPF，给我的一个感触就是：垃圾。
WPF这个界面类库本身能够实现很多种效果，确实非常难得，但是总感觉它自身就像是拼凑起来的一堆辣鸡，而没有贯穿始终的思想。让人摸不到头脑。

WPF的XAML

XAML本身是一种界面描述语言与WPF是两种东西，为了简化界面编程工作WPF引入了XAML，为了在XAML中更加方便的引用WPF，对于XAML本身和WPF都做了很多乱七八糟的改进。

1. XAML中的元素属性赋值，可以采用属性赋值语法在元素标签内赋值，还可以采用成员赋值办法，在XAML标签内部作为成员赋值。这都不是灵活性的问题了，形而上学上来看，简直是没有一个统一的思路，过于松散想怎么搞就怎么搞。
2. 属性分为普通属性与附加属性，这个附加属性表现为Grid中的元素一般都有一个Grid.Row，Grid.Colum属性，Canvas元素中的成员一般都有Canvas.left，Canvas.Right属性。而如果要使用代码设置Canvas的成员位置需要使用静态方法，Canvas.setLeft(UlElement,double)，Canvas.SetRight(UIElement,double)函数。这都是不合理的。既然是在一个实例化的元素上设置内部实例化的对象的属性，就应该采用成员语法的方式，而不是采用静态方法啊。静态方法特别恶心。
3. 还有就是利用XAML声明的方法很容易达成的效果，利用代码来说非常困难，需要很多步骤，有时候可是很奇葩的步骤。为什么XAML中使用起来是那么的容易？因为微软为了你做了大量的工作。但是如果你想利用C#代码调用一些功能，丰富一些效果的时候，这是非常困难的，因为XAML与WPF本身是两种完全不同的思路，你需要的是重新学习一个类库。
4. XAML其实就是另一种形式的C#代码，它内部所有的标签都会转化为一个控件，所有的属性都会转化为C#语句调用，他是解释性的，而不是描述性的。他的本质是使用了内置控件的特性完成的。也就是说它的核心还是WPF内置控件。而不是利用描述语言模拟一个控件。WPF是硬的，而HTML是软的。从拓展性上来看，ＷＰＦ不如HTML。问题是这么一搞，C#代码和XAML语句并不是一一对应的。因为XAML中的一个属性可能对应着大量的WPF操作。这让人摸不到头脑，微软只是推广XAML，因此支队XAML做了相当多的简单工作，却没有反向过来优化WPF的架构，因此很混乱。微软推荐使用XAML的描述性语法，引入了很多模板行为支持，但是这种支持在ＷＰＦ代码中是不存在的。

好的UI类库

一下纯属我的个人看法，不喜勿喷。

1. 作为一个设计良好的类库而言，我觉得最重要的核心还是类库的架构，最核心的其实还是软件代码。如果利用代码编程体验很糟糕，就说明这个类库非常有问题。毕竟对于一个程序来说。代码才是可拓展的一切的基础，只有代码编程体验良好才是真正的好类库。
2. 作为一个类库开发界面设计器没有问题，采用XML语言作为描述语言同样没有问题，但是XML语言与代码一定要一一对应，这样XML描述语言才有意义，维护起来也很方便，只需要简单的映射一下就可以了，不会让人产生一种割裂感。
3. 界面类库应该提供最灵活的底层机制，提供给开发者最灵活的拓展手段，而且这个拓展手段一定要简单方便，实用高效，富有哲学美感，与界面库的设计哲学和谐统一。例如提供给开发者最基本的原子控件，方便开发者组合设计自己的专属控件。
4. 界面类库一定要提供封装好的控件，而这个封装好的控件一定要基于界面库的灵活的底层机制，就是利用提供给开发者的那些底层机制，这样这些控件的呈现就是对自定义控件最好的demo。体现界面类库强大的同时，还能方便代码编写。因为不是所有人都喜欢自定义控件的，有些人不在意控件，只要能用即可。
5. 界面库需要提供一条简单清晰的学习路线，而不是功能的堆积和一堆无用特性的堆积修补。例如：刚入门界面类库，首先需要学习基本代码调用编写简单界面，这个过程需要的是简单，和谐，统一化的体验。这之后学习XML描述文件的编写，XML描述文件需要的是与代码一一对应，这样一来代码知识就很容易的完成迁移。再然后，学习控件的编写，剖析官方控件，为有需要的开发者提供一个自定义界面的手段。这样开发者需要学习那种知识，需要学习到那种程度就非常方便了。
6. 在XML中提供了那些便捷的工具，同样需要在代码编程的时候提供同等方便的工具。