WPF是微軟推出的一個先進的界面類庫，具有高度的可定製性，吸收了很多html的思想，打破了傳統的假面編程思路，很有創造力。
尤其是當WPF採用了XAML作爲界面描述語言之後，更加簡化了WPF編程的難度，專門設計的Visual studio編程IDE對於WPF的支持更是無以復加，稱得上是絕配。
但是，學習了這麼久的WPF，給我的一個感觸就是：垃圾。
WPF這個界面類庫本身能夠實現很多種效果，確實非常難得，但是總感覺它自身就像是拼湊起來的一堆辣雞，而沒有貫穿始終的思想。讓人摸不到頭腦。
WPF的XAML
XAML本身是一種界面描述語言與WPF是兩種東西，爲了簡化界面編程工作WPF引入了XAML，爲了在XAML中更加方便的引用WPF，對於XAML本身和WPF都做了很多亂七八糟的改進。
- XAML中的元素屬性賦值，可以採用屬性賦值語法在元素標籤內賦值，還可以採用成員賦值辦法，在XAML標籤內部作爲成員賦值。這都不是靈活性的問題了，形而上學上來看，簡直是沒有一個統一的思路，過於鬆散想怎麼搞就怎麼搞。
- 屬性分爲普通屬性與附加屬性，這個附加屬性表現爲Grid中的元素一般都有一個Grid.Row，Grid.Colum屬性，Canvas元素中的成員一般都有Canvas.left，Canvas.Right屬性。而如果要使用代碼設置Canvas的成員位置需要使用靜態方法，Canvas.setLeft(UlElement,double)，Canvas.SetRight(UIElement,double)函數。這都是不合理的。既然是在一個實例化的元素上設置內部實例化的對象的屬性，就應該採用成員語法的方式，而不是採用靜態方法啊。靜態方法特別噁心。
- 還有就是利用XAML聲明的方法很容易達成的效果，利用代碼來說非常困難，需要很多步驟，有時候可是很奇葩的步驟。爲什麼XAML中使用起來是那麼的容易？因爲微軟爲了你做了大量的工作。但是如果你想利用C#代碼調用一些功能，豐富一些效果的時候，這是非常困難的，因爲XAML與WPF本身是兩種完全不同的思路，你需要的是重新學習一個類庫。
- XAML其實就是另一種形式的C#代碼，它內部所有的標籤都會轉化爲一個控件，所有的屬性都會轉化爲C#語句調用，他是解釋性的，而不是描述性的。他的本質是使用了內置控件的特性完成的。也就是說它的核心還是WPF內置控件。而不是利用描述語言模擬一個控件。WPF是硬的，而HTML是軟的。從拓展性上來看，ＷＰＦ不如HTML。問題是這麼一搞，C#代碼和XAML語句並不是一一對應的。因爲XAML中的一個屬性可能對應着大量的WPF操作。這讓人摸不到頭腦，微軟只是推廣XAML，因此支隊XAML做了相當多的簡單工作，卻沒有反向過來優化WPF的架構，因此很混亂。微軟推薦使用XAML的描述性語法，引入了很多模板行爲支持，但是這種支持在ＷＰＦ代碼中是不存在的。
好的UI類庫
一下純屬我的個人看法，不喜勿噴。
- 作爲一個設計良好的類庫而言，我覺得最重要的核心還是類庫的架構，最核心的其實還是軟件代碼。如果利用代碼編程體驗很糟糕，就說明這個類庫非常有問題。畢竟對於一個程序來說。代碼纔是可拓展的一切的基礎，只有代碼編程體驗良好纔是真正的好類庫。
- 作爲一個類庫開發界面設計器沒有問題，採用XML語言作爲描述語言同樣沒有問題，但是XML語言與代碼一定要一一對應，這樣XML描述語言纔有意義，維護起來也很方便，只需要簡單的映射一下就可以了，不會讓人產生一種割裂感。
- 界面類庫應該提供最靈活的底層機制，提供給開發者最靈活的拓展手段，而且這個拓展手段一定要簡單方便，實用高效，富有哲學美感，與界面庫的設計哲學和諧統一。例如提供給開發者最基本的原子控件，方便開發者組合設計自己的專屬控件。
- 界面類庫一定要提供封裝好的控件，而這個封裝好的控件一定要基於界面庫的靈活的底層機制，就是利用提供給開發者的那些底層機制，這樣這些控件的呈現就是對自定義控件最好的demo。體現界面類庫強大的同時，還能方便代碼編寫。因爲不是所有人都喜歡自定義控件的，有些人不在意控件，只要能用即可。
- 界面庫需要提供一條簡單清晰的學習路線，而不是功能的堆積和一堆無用特性的堆積修補。例如：剛入門界面類庫，首先需要學習基本代碼調用編寫簡單界面，這個過程需要的是簡單，和諧，統一化的體驗。這之後學習XML描述文件的編寫，XML描述文件需要的是與代碼一一對應，這樣一來代碼知識就很容易的完成遷移。再然後，學習控件的編寫，剖析官方控件，爲有需要的開發者提供一個自定義界面的手段。這樣開發者需要學習那種知識，需要學習到那種程度就非常方便了。
- 在XML中提供了那些便捷的工具，同樣需要在代碼編程的時候提供同等方便的工具。