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