Extjs和Flex的聯系
本文和大家重點討論一下Extjs和Flex的聯系，Flex是良好的輿論口碑、漂亮的ui組件、高度耦合的B/S層server數據可便捷取到browser的能力及富客戶端的體驗。而Extjs不是全部收費、漂亮的界面可以滿足項目的需求、文檔&api都很到位、擔憂的性能Extjs也很關注的在每個升級版本中優化提升。
Extjs和Flex的聯系
開發面臨的是需求與性能，第三方的選擇在于團隊整體水平、需求的滿足、性能的可承受性、口碑&發展的前景及日后的維護成本；
1、Extjs在webui這一塊做的的確不錯，學習曲線不是什么難題，我想在趨向收費性的Extjs和出身高貴的dojo中選擇，你應該會選擇前者，至少我是，原因很簡單：Extjs還不是全部收費、漂亮的界面可以滿足項目的需求、文檔&api都很到位、擔憂的性能Extjs也很關注的在每個升級版本中優化提升，而dojo雖出身名門，得到大公司的青睞，但有一個致命傷--文檔少、api升級變動、可能有些模塊性能也不怎么穩定，這一點大家可以關注下struts2，struts2也選擇了dojo，也是因為dojo的這種闊公子無章法的變動使得struts2的這部分開發其實也很痛苦，struts2-dojo-plugin據說也是出于此而誕生在struts2.1版的；
2、Extjs與jquery其實沒有可比性的，因為他們各自的出發點和落腳點不在同一個平臺上；當然，你若擔心Extjs的性能，又偏愛于jquery，那么，你完全可以考慮用jquery+css+div的方式來DIY輪子或者用jquery的ui插件來實現Extjs類似的你所需要的功能，這里你是不是已經發現了一個問題：jquery封裝實現類似Extjs提供的功能！對，就是它，它至少可以回答你兩個問題，一是Extjs和jquery的可比性其實不大，二是Extjs的性能整體來說弱于jquery，但話又說過來了，若你將jquery封裝到Extjs的級別，那兩者的性能對比將又如何？天知道，至少我不知道，永遠的矛盾--易用性與性能，封裝的層次越高，應用、維護起來越方便，性能的擔憂也就越多了，不單單web開發，純后臺的項目也是如此，而且純后臺的項目更注重性能，易用易維護的封裝層次與性能及靈活性永遠是矛盾的共存體，如何取舍由你，但效果最終還是取決于項目終端用戶體驗的滿意度，因為那才是財源；
PS：之說以這么說是因為我最近做了一個純后臺的項目時遇到持久層的性能瓶頸爭論問題，我給大家一個粗略的性能測試數據，即便我不說，相信大家橫行對比也知道這里面的含義了(據說C的oracleoci可以到達3k條/秒的insert速度，而我測java的oci或thin***測試記錄也無非1.3k多條/秒，比較汗)：
測試環境：主機HP-UXrp3440B.11.23U9000/800(td)數據庫ora9i
插入速度測試數據
模式驅動模式數據量2w2w10w10w
原始jdbc模式thin時間(速率)17秒(1176條/秒)18秒(1111條/秒)1.26分(1162條/秒1.26分(1162條/秒)
oci18秒(1111條/秒)18秒(1111條/秒)1.25分(1176條/秒1.28分(1136條/秒)
JdbcTemplate模式thin24秒(833條/秒)24秒(833條/秒)1.59分(840條/秒)1.54分(877條/秒)
oci29秒(689條/秒)29秒(689條/秒)2.33分(653條/秒)2.21分(709條/秒)
ibatis兩種驅動模式下插入速度大約在400多條/秒，ibatis的批量可以達到[5400,6000](條/秒)當批量值在[500,1000]條之間選擇時
從測試數據可以看出，OO易用性越好封裝抽象層次越高，性能相對越低，未來的改良可能采用DBUtil了，因為后臺這種多數情況下即時insert項目緩存的意義并不太明顯，有種越走越底層、越走越原始的感覺，難道人生***的***境界真的是返璞歸真？
PS-Java是個開源的世界，存在眾多可選性，為避免重復制造輪子、快速開發，使用現有的第三方是有益的舉措，但要做到使用第三方能夠快速、高性能的完成項目開發，必須嚴把選擇關，從需求滿足、開源廠商、用戶群、口碑、性能、前景等等，多方位、多角度的衡量第三方，一旦確定下第三方就要深入的去研究，為我所用；
3、再說Flex，若對比Extjs與Flex，無非也是ui與性能，事物都是兩面性的，所以，我比較不出所以然來，但我們不妨換個角度來看下：
Flex吸引你眼球的地方是什么呢？我想無非是良好的輿論口碑、漂亮的ui組件、高度耦合的B/S層server數據可便捷取到browser的能力及富客戶端的體驗(類似于js與dwr的關系，此況下似乎高度耦合我們也并不介意，也許面向接口編程緩和了高耦合的批判度，所以，不要過分技術...有點扯淡我*_*)；Flex的確走出了一條新路子，它的新得益于門出adobe，受益于flash環境及actionscript腳步；我們不妨這樣肢解一下Flex：
a.組件式的漂亮UI；
b.actionscript的腳本編程；
c.flash的運行環境；
d.B/S的間通信協議；
◆它的著力點在哪里呢？adobe利用flash的優勢，打造web富客戶端體驗的application開發模式，個人觀點，我為什么這么說呢？我們可以從以下幾點來看：
一、傳統的web開發，主要是靠js+div+css來美工界面的，js雖有意高攀java但兩者并無任何必然聯系并終因其前期難以開發、調試、跨瀏覽器的差異性及非真正面向對象的語法以及所謂的js加載性能的討論，使得開發人員對js是愛恨交錯；
二、ajax的風靡使得客戶體驗度大大提升，漸進沉寂的js又二度開春，再度被狂熱追捧，這個過程也反映了web開發UI是軟肋，說明web開發需要豐富的UI，需要非傳統的web體驗，開發人員期待能用像RAD方式開發application系統的方式來完成web的開發，簡捷的、豐富UI及便捷的UI與后端數據交互，這應該是jsf做的路線吧；
三、ajax之前就已經存在jsf，jsf也是正統出身，旨在UI，推了好久，但始終不溫不火，不知其中緣由，但jsf給我的感覺配置多于編碼，這個讓我受不了；
四、接下來的代表應該是gwt了，是google推出的一套開發基類庫，將開發完全分為client/server模式，無js代碼，因為gwt會為你代勞，這也許是不擅長js而渴望開發出漂亮UI的web應用的朋友們的福音，也許google的原因吧，gwt還是蠻有影響力的；
五、Extjs著力于webUI的js類庫，再看gwt-ext及ext-gwt，都著力在web開發UI及客戶體驗上；
我們是否可以這樣看下去：傳統web開發ui的軟肋(js+div+css)-->帶寬增加、數據交互能力、客戶體驗度的提升(ajax)-->一方面UI的需求(air、Extjs)，一方開發模式的轉變(jsf，gwt，gwt-ext)-->以上的webUI最終體現腳本js，解析依賴于各瀏覽器；存在肢解的元素a.組件ui；b.js腳本；c.瀏覽器運行環境；d.http協議(當然ajaxrpc)-->終于到了炙手可熱的Flex；這應該是發展的根本所在吧~
【編輯推薦】
