wpf和wdf的差別

wpf&&wdf是兩個不同産品，一個是webphere portlet factory，後者則是Workplace Dashboard Framework。他們的前身是bowstreet（Gartner Group評估的六家Web服務領域最領先的企業之一）的産品，原名是bowstreet portlet factory。後bowstreet被IBM收購，于是portlet factory也改名稱之為IBM portlet factory了，隻不過在這個基礎上多了個dashboard。

要把兩個産品的異同說出來，看起來是非常簡單，但是可能會讓人有些混淆。兩個東西說白了，其實都是soa程式設計模型的一個咚咚，都是可以可eclipse，rad之類內建，作為插件使用的。兩個都是快速開發portlet的工具。唯一不同的就是dashboard更偏向于資料的展現。而portlet factory更傾向于業務邏輯。比較混淆的地方就是，dashboard安裝後，就自動含有portlet factory所有的功能和builder了。這東西我也搞不明白了，不是IBM同一個産品線的東西，但是功能卻是一個涵蓋另外的一個所有功能（dashboard涵蓋了portlet factory的所有功能），那麼其實我們隻要安裝一個dashboard就夠了，事實上我們的确一般隻需要安裝一個dashboard就足夠。前面忘了提到的比較重要的一點是，portlet factory是免費的，dashboard是收費的。這個大概就是為什麼dashboard涵蓋portlet factory的所有功能的一個主要原因吧（讓人感覺portlet factory是dashboard的試用版）。

我研究dashboard是從portlet factory開始的，當初僅僅是為了個參數傳遞都折騰了老半天的。portlet factory，字面的意思是portlet 工廠。當然它的确是個portlet “工廠”，通過portlet factory做出來的東西都是可複用的，通過裡面builder建的model，你可以随便複制到哪用使用，唯一的前提是要保證目錄結構和目錄名一緻。它的開發過程是類似向導型。又有些像搭建積木，通過一塊塊的積木，你可以搭建成各式各樣的工程。portlet factory裡面的builder是裡面的最小“積木”原型，通過這些builder，你可以構造出一個個有單獨功能的model。并将model封裝成一個服務，提供接口。供服務調用者使用。是個典型的soa模型。在portlet factory裡面，所有的東西都可以做成一個服務，并提供給調用者使用。當然除了builder和model之外，portlet factory還有個比較重要的元件，profile（最難了解的一個東西），這個東西相當于是一個定制的東西吧，通過profile，你可以定制多套展示方案，可以為你的工程根據群組設定通路權限之類的。

portlet factory還有個比較好的地方就是，在你建立工程之後，隻要你不加portlet擴充卡builder将其構成一個builder，那麼他就是個普通的j2ee應用程式。在調試的時候它也都是以j2ee應用的方式在運作。并且可以作為一個j2ee工程部署到was上面。當然這個其實并不是它的優勢。它的優勢在于它的快速開發和dashboard上面的資料的展現。這兩個才是dashboard是以得賣點。

至于dashboard就簡單點說了，除了上述的之外，還有的就是它之是以大推特推的賣點（資料展現），dashboard的資料展現有着其它portlet開發工具所沒有的資料展現能力，美觀、大方、可定制、快速。這些綜合起來，很少portlet 開發工具有這麼強大的功能了。它包含了警報，預警、webchart等builder，可展示的圖有雷達圖、儀表盤、普通的柱圖，曲線圖之類、餅圖等等等等。通過這些我們能夠很清楚的對大量的資料進行分析。能夠讓使用者（一般都是上司級人物）快速的看到走向以及做出分析。因為有了這些功能和IBM做背景。是以産品能夠“重推”吧

在我看來，雖然倆産品都是打着soa理念，我并不排斥soa理念。有着很多外表胡裡花哨的東西。而且做得東西的确很快，用rad我們做一個簡單的隻有一個小小功能的portlet，肯定得半個小時以上。但是用dashboard隻需要2分鐘，假如你熟悉了的話。但是wpf&&wdf還是劣迹斑斑。總的來說有以下理由

一、産品不夠成熟，雖然推出了這麼久，但是這兩個産品還是有不少的問題，bug挺多的。在開發中很容易出現的，比如中文問題，上次ibm專家過來解決過，使用的是IBM一向對問題的解決辦法：打更新檔包。還有類似的比如出現main null GB18030什麼什麼的問題，那個問題很常見。ibm的專家對dashboard和建立的工程裡面的所有的factory打了個jar包重起下就ok了。事實上這個問題并沒有得到解決，我們後來再次測試還是偶爾會有那個個問題存在。還有就是那個”SQL調用“builder“裡面不支援中文，還有的就是在測試的時候是正常的，但是會出現随機性的不可用現象。這個問題如果出現在現場，我想使用者可能受不了了。

二、所謂的”靈活“，這裡其實是相對的，可定不如直接用程式設計開發來的靈活的。但是我覺得他一點都沒有靈活可言。就拿那個model複制來說吧，從産品介紹裡面說是這個東西可以直接複制并使用的。但是如果你要是目錄不同，或者說結構稍微有變，那麼這個model就不可以使用了。還有比如資料源，如果兩邊資料源不一緻，那麼model複制過去肯定是會出問題的，這個時候如果你重新配置資料源那也得改下那裡面用的”服務操作“builder，因為這個東西是在儲存後立即和資料庫連接配接并編譯的。如果這個時候連接配接不到資料庫會對後面的操作有影響的，并且會自動改變很多配置項。如果你不重新配置資料源，采用在builder裡面重新修改成已有的資料源的話，那麼它也會重新的改變後面的配置項，至于後面的操作，和你重新配置一個新的model是一樣的。還有的就是dashboard的圖表的展現。倒還不是那麼不靈活的，可以采用webchart繪圖之後把xml複制過去，然後對所需要展示的圖表的樣式改稱連結這個xml就可以了。從這些來講，其實它是非常笨的一個東西的。

三、入門容易，學好很難。雖然說java入門容易，但是這個東西入門更加容易，你要想成為一個普通的copy型的程式員，我建議就學portlet factory算了。好歹更易入門。隻要是一些比較簡單的業務邏輯沒有什麼程式設計基礎的人都能夠做出來的。但是要想學到和非常的深，象java中進階程式員一樣，那麼你得付出比用java學到同樣水準的java程式員更努力了！據上次教育訓練老師說，國内使用過三分之一以上的builder的人都不多，如果你能學到三分之二，那也能算個不錯的高手了。用到過所有的builder的人，在全球估計都是獨孤求敗了！

四、不适合做複雜業務邏輯的東西，wpf隻适合做些難度一般以下的業務邏輯的東西。如果邏輯過于複雜的話，受靈活性限制，估計要寫些程式來控制了，還有就是邏輯過于複雜的話，配置項也不能夠和其中的一些builder有沖突，否則的話出現錯誤很難查找。而且工程的可控制性也不強。

以上就是我對wpf&&wdf的一些看法，之是以有些寫wdf有些寫wdf有些寫wdf&&wdf。是因為有時候他們都可以混合起來講！以後哪我建議這兩個産品最好和成一個，wpf就作為試用版算了，wdf就作為正式版，如果要得話就拿錢買，以免總是混淆。但是不知道IBM搞這個的人肯不肯呢！

-----------------

我把這兩個從IBM正版盤裡拷出來,準備學學,研究一下哪個好用.