深刻淺出WPF——什麼是XAML

小序：

還記得周星馳那句話嗎？「人若是沒有理想，那跟鹹魚有什麼區別」。當本身一步踏上追求理想的征途，才發現爲了理想要放棄不少、不少……只有這時候才能切身地明白到什麼叫「捨得」。

向全部關注個人朋友們彙報一聲，我開始動筆寫《深刻淺出WPF》了。如今大概已經完成了兩三章的樣子，我會把一些片段陸續發佈到blog裏，請你們多提寶貴意見。

我知道，當我最疲憊、最沒有激情的時候，惟一能激勵我走下去的，就是朋友們和編輯們的鼓勵！

我須要大家！

 

正文：（彷佛今天的正文最簡單不過了——直接Copy再Paste就搞定了！）

 

 

1. XAML是什麼？ 自人類社會誕生，社會分工就在不斷地進行着。從原始社會畜牧業與農業分離到當 今社會成千上萬行業的彼此協做，無不是社會分工的傑做。社會分工的意義在於它能使從事固定工做的人羣更加專業化，並經過合做的形式提升生產效率。換句話 說，在合做不是問題的狀況下，若干羣專業人士配合工做要比同等數量的一羣「大而全」人士的工做效率高。 這種分工與合做的關係不只存在於行業之間，也存在於行業內部。軟件開發中最典型的分工合做就是設計師（Designer）與程序員（Programmer）之間的協做了。在WPF出現以前，協做的場景通常是這樣： 1. 需求分析結束後，程序員對照需求設計一個用戶界面（User Interface，UI）的草圖，而後把精力主要放在實現軟件的功能上 2. 與此同時，設計師們對照需求、考慮用戶的使用體驗（User Experience，UE）、使用專門的設計工具（好比PhotoShop）設計出優美而實用的UI 3. 最後，程序員按照設計師繪製的效果圖，使用編程語言實現軟件的UI 經驗告訴咱們，即使是優秀的設計師團隊和優秀的開發團隊合做，花費在溝通和最終整合上的精力也是巨大的。常常出現的問題有： • 設計師的設計跟不上程序邏輯的變化 • 程序員未能徹底實現設計師提供的效果圖 • 效果圖與程序功能不能徹底匹配 • 從效果圖到軟件UI的轉化耗費不少時間 這些並非誰對誰錯的問題——只要存在分工，那麼合做的成本就不可能爲零。問題的核心在於，上述的合做是「串行」的，也就是先由設計師完成效果圖、再由程序員經過編程實現。若是設計師能與程序員「並行」工做、直接參與到程序的開發中來，上述的問題就迎刃而解了。 解決方案是什麼呢？是讓設計師們使用編程語言來設計UI效果圖，仍是讓程序員們使用PhotoShop來開發程序？顯然都行不通。 網 絡程序開發團隊的經驗卻是很值得借鑑：草圖產生後，設計師們可使用HTML、CSS、JavaScript直接生成UI，程序員則在這個UI產生的同時 實現它背後的功能邏輯。在這個並行的合做中，設計師們可使用Dreamweaver等設計工具，程序員使用Visual Studio來進行後臺編程。有經驗的設計師和程序員每每還具有互換工具的能力，這使得他們能基於HTML+CSS+JavaScript這個平臺進行有 效的溝通。 爲了把這種開發模式從網絡開發移植到桌面開發和富媒體網絡程序的開發上，微軟創造了一種新的開發語言——XAML。XAML的全稱是 Extensible Application Markup Language，即「可擴展應用程序標記語言」。它在桌面開發及富媒體網絡程序的開發中扮演了HTML+CSS+JavaScript的角色、成爲設計 師與程序員之間溝通的樞紐。  如今，設計師和程序員們一塊兒工做、共同維護軟件的版本，只是他們使用的工具不一樣——設計師們使用Blend（微軟 Expression設計工具套件中的一個）來設計UI，程序員則使用Visual Studio開發後臺邏輯代碼。Blend使用起來很像PhotoShop等設計工具，所以能夠最大限度地發揮出設計師的特長。使用它，設計師不但能夠制 做出絢麗多彩的靜態UI，還可讓UI包含動畫——雖然程序員們也能作出這些東西，但從專業性、時間開銷以及技術要求上顯然是划不來的。更重要的是，這些 絢麗的UI和動畫都會以XAML的形式直接保存進項目，無需轉化就能夠直接編譯，節省了大量的時間和成本。  下次，當你在面試被問到「什麼是XAML」時，你能夠回答：XAML是WPF技術中專門用於設計UI的語言。