作者：周銀輝
原文出處：http://www.cnblogs.com/zhouyinhui/archive/2008/01/17/1042740.html
1，舊的模式已經不再適用
首先看看如果我們將舊的（.net3.o之前）模式直接引入到WPF中將是如何工作的。無論采用什么樣的溝通方式，我們需要Developer和UI Designer之間對軟件的功能達成共識，然后我們可以得到當前界面的大體Layout，OK，這個被驗證和確定以后，UI Designer會細化他的工作，提出一些她的一些新觀念，軟件UI風格，然后細化出一張張的效果圖（利用PhotoShop，PowerPoint等等)。接下來，Developer所要做的事情是："照葫蘆畫瓢"，照著UI Designer的效果圖，再Blend中將其模擬出來，以便形成可供程序使用的XAML。我們可以將這個過程稱之為Translate（將效果圖（PNG，Jpg）翻譯成XAML）。
這所帶來的問題：
(1)UI Designer的大部分"產出"的丟失，我們知道UI Designer除了告訴我們UI應該是怎樣來展現以外，其設計過程中的大部分作品被拋棄掉了（比如設計了很長時間才做得很漂亮得一個按鈕圖片），這是由于其產出不能直接用到我們的Project中（我們要得是XAML而不是PNG,Jpg）。到最后UI Designer那邊好像僅僅給我們提供了很多idea，而沒有實質性的東西輸出給我們以便用于我們的的Project.
(2)Developer這邊"費力不討好"。所謂"費力"指的是就大多數Developer而言本身就不擅長繪圖（即便您有Blend這類傻瓜式的工具），所以你很難得再Blend中將美工那邊提供的圖形完全模擬出來，所以，Designer那邊有意見了，您將人家美麗的藝術品轉化得一團糟糕了。即便某某很牛，模擬出來了。仍然"不討好"，因為這是重復勞動，Developer再Blend中做得這部分工作事實上美工再Photoshop（或其它）中已經做過一次了。
一個可能得疑問是：為什么不讓UI Designer們再Expression Blend或Expression Design中工作呢？先說在Expression Blend中工作，除了培訓成本（我想這個培訓成本應該是相當高的）以外，就大多數UI Design團隊而言面臨的最嚴重的問題是：他們沒有軟件開發的觀念和知識，無法將他們融和到開發流程中來，如果他們負責Blend這塊的話，他們的一舉一動將直接影響軟件的性能和功能。比如他們不會按照Developer的觀念來合理組織資源，他們不會考慮XAML代碼對性能的影響，沒有模塊話的觀念，不會顧忌軟件的可維護性，穩定性。他們只會關心"這樣的界面簡直太漂亮太好用啦"。那么結果可想而知。再說Expression Design，事實上這是可行的，如果老板愿意出這部分培訓費用和培訓時間以及UI Designer樂于使用新工具的話。
2，新的模式有那些？
新的模式有好幾種，這取決于團隊中成員的技能和職責，但我比較推薦的有兩種。
(1)集成模式
從WPF角度看，團隊中除了UI Designer和Developer以外，我們再引入一個新的角色Integrator。首先看看他們各自的職責：UI Designer的職責保持不變，但我們稍稍改變一下她的"輸出"，其除了輸出各種idea，布局圖，效果圖等等之外，其還將為我們輸出其它所有的圖形（比如一個漂亮的按鈕），但是以XAML的形式（這會用到一些插件或小工具，你可以在這里找到http://www.cnblogs.com/zhouyinhui/archive/2007/12/08/987928.html）。請注意，其輸出的是一些松散的XAML零部件，僅僅描述了圖形，沒有Style，Template，Trigger，Resource等概念。這樣UI Designer既不會改變慣有的工作方式，又可以專注與圖形和用戶體驗。而Developer的職責也保持不變，其專注于后臺邏輯，但放棄對界面的所有權，其是C＃（或其它）的擁有者。而Integrator將致力于他們兩者之間的結合，其負責將從UI Designer那里得到的松散的XAML按照軟件開發者的觀念在Blend中組合成真正的項目中的零部件，比如其將負責Template，Style，Animation以及界面的模塊化，資源的組織，考慮其可維護性，穩定性，對性能的影響等等，其是XAML與Blend的擁有者。
這有一些明顯的好處：
(i) 沒讓成員做不擅長的事。在舊模式中，讓Developer在Blend中繪制出藝術品或者讓UI Designer按照開發者的觀念來管理Blend端顯然是強人所難，并且這也會分散他們的精力甚至帶來抱怨。但目前的模式將這些負擔轉移出去了。
(ii) 避免了重復勞動。舊模式中，Developer來"翻譯"UI Designer的成果的勞動是重復和痛苦的。而當前模式中圖形的XAML直接來自于UI Designer。我們需要做的僅僅是整合。
(iii) 避免了實際"翻譯"出來的UI與設計時的UI的不一致。兩者差距有多大完全取決于Developer的"翻譯"能力，但往往效果時不理想的，以至于UI Designer覺得自己的藝術品被扭曲了。
(iv) 有人專注于Blend端，那么軟件的表現層端質量將更高，更容易維護。
(2)收割模式
從WPF角度來看，這個模式中只有兩個角色: UI Designer與Developer。這個模式對UI Designer的要求較高，其需要能熟練使用Blend來創造一些成品供Developer"收割"。比如我們需要一個漂亮的按鈕，那么UI Desinger直接輸出給我們該按鈕的Style。其甚至可以輸出其它更復雜的東西，比如UserControl（不可能是CustomControl，因為他們不會寫程序邏輯，除非和Developer合作）。他們的工作是在解決方案中的某個輔助項目中完成了，而負責軟件的真正表現的Blend端由Developer來負責，因為這里需要考慮很多軟件開發的東西。
該模式同樣擁有集成模式的各種好處并且與集成模式相比，UI Designer更加融入到了項目開發過程中，但對UI Designer的要求較高。
其它一些建議：合理地整合Blend端，如果發現XAML文件過大就模塊化。保持UI項目始終能用Blend打開，否則將導致團隊中某些角色出局或工作起來很麻煩。別讓界面和邏輯耦合在一起，如果發現邏輯對界面元素引用過多，那么可能在Binding，Trigger，Resource等方面做得不夠好。另外，相比之下，我更推薦第一種模式，我在這種模式下工作了不短時間，Integrator是我的職責之一。