專刊內文

當前位置:首頁>專刊分享>內文

瀏覽次數 : 4223



 

jQuery讓EEP更快更親和

訊光科技 / 高志明
 

前言

            EEP從2005踏上.NET的路途以來,也已經有8個年頭了,一路上從ASP.NET到Ajax Extended,接著是Ext,然後是Silverlight,最後走到jQuery來,這路途可真遙遠,也很辛酸。長期以來,客戶們總是在Web方案的效能與UI上打轉,我們的研發團隊經常是高度壓力下匐匍前進,目標只有一個,讓User享受更高的效能,更好的用戶體驗。 

jQuery是公認最受歡迎的JavaScript開源程式庫,全球目前有數百個社群提供現成的組件供開發者自由免費下載,不但如此,目前在全球最知名最熱的前一萬個網站中,59%在自家的網頁上都使用了jQuery。 隨著微軟MVC開發模式漸為潮流之際,jQuery儼然已經成為View(使用者介面)的最佳開發方案;而在EEP的分層式架構中,擁有強大的管理機制與成熟穩定的EEP A/P Server,就成了Model的最佳模型與商業處理邏輯架構,隨著VS2012上市之際,EEP2012也順勢搭上jQuery這班時代列車。

 

Web的發展與效能

過這15年Web的市場發展,我們就從技術與效能及UI上的背景來述說發展的歷程,讓我們以時光隧道快速回朔過去的階段: 

1.     ASP/PHP的時代:這種古老的技術,到現在還是存在,不少人還在用這些技術維護著,尤其是網站的部分,其實這種輕量級的網頁執行效率還真的不錯,非常精簡有效率,只是當時並沒有AJAX技術,否則這種架構的速度絕對不輸給現在任何一種架構。ASP最與人詬病就是一天到晚中毒與被駭客攻擊,因為架構上的缺陷導致很難根除此問題;另一個就是寫的很分散,一個頁面程式,經常要用多達3~4個ASP/PHP才能夠完成,造成維護的困擾。

2.     ASP.NET的時代:2002年,微軟推出.NET之後,就是要將原本的ASP取代,當然那時還很少人跟進,一直到2005年推出.NET 2.0之後(開發工具為VS2005),ASP.NET才開始被大量應用在企業網站與WEB應用軟體上。ASP.NET原本標榜是預編譯與Code-Behind,理論上效能將比ASP佳才對,但觀念上使用Server Control,很多User動作都會往返網頁加上ViewState的方式(將Server Control的物件狀態序列化在網頁中,以利回到Server時物件狀態可以保留),讓ASP.NET所開發的WEB應用系統普遍效能不佳,除非開發者刻意少用Server Control與將ViewState關掉,這樣又會因為優化必須多寫的很多程式而造成困擾。

3.     AJAX的時代:2006年起,AJAX觀念開始流行,AJAX就是Asynchronous JavaScript And XML縮寫,代表非同步的JavaScript 和 XML,簡短地說就是在不重新整理網頁(Postback)的情況下,AJAX 透過非同步的方式與後端交換資料,並可立即在網頁上進行局部顯示。當時微軟為了提供類似功能,於2007推出了ASP.NET AJAX Extension,主要提供了一個非同步的機制,讓網頁可以透過AJAX即時與User互動或背景傳輸資料等等,這樣網頁就無須老是要整頁更新,可以指定某一個區塊來更新即可,如此,將可大大改善網頁的效能與使用者介面的親和度。

4.     RIA的時代:就在大家吵著甚麼是Web 2.0時,以Adobe為主的Flash及微軟的Silverlight就從此開戰,這兩種技術都是使用插件的方式,早期因為網頁沒有繪圖與Mouse細膩拖拉事件,就需要網頁嵌入一個插件能在設備本機上執行特殊功能。一般網頁前端沒有甚麼工作能力,但前端的設備也許是高端的PC或Notebook,加上網頁大都沒有離線的處理能力,於是就會有RIA的觀念出現,(Rich Internet Application,豐富的網頁應用程式),希望能滿足越來越挑剔的使用者需求。基本上走向RIA並沒有甚麼錯誤,問題就在,時代變化得太快了,iPhone iPad的快速崛起,讓RIA受到很大的壓制。誰也沒想到智慧型手機與平板電腦的成長這麼快速,早早凌駕PC與NB的出貨數,如果這些設備無法執行這些RIA插件,那再好的技術與使用者介面也無用武之地,這也是RIA無法走下去的主要原因。 

走到此,RIA也沒錯,只是是否能跨平台跨裝置呢?答案是否定的,就這樣,WEB的開發必須重新被思考,加上,HTML5的規格於去年底被W3C定案了(候選推薦版),更促使所有的設備都將朝向支援HTML5為重大目標,而HTML5中有部分包含了RIA繪圖與離線的功能定義,似否意謂就HTML5來實現RIA的特殊功能是可行的。因此,在沒有更新更成熟的技術之前,使用HTML5加上AJAX看來是最好的WEB方案,而在眾多的AJAX框架中,被使用最多jQuery就成了大家的首選,可能也因為jQuery的資源充足,免費,群聚的效應使然吧。

 

EEP的jQuery方案 

EEP的基本理念就是包裝常用的元件,讓開發者以屬性填寫的方式,不必寫程式即可完成工作,但由於使用者介面需求與變化很大,往往元件的方式無法達到100%滿足度,甚至有些用戶只有60%滿足度,此時就必須以Code來協助解決,這當然是合理的,但往往開發者在元件與Hard-Coding間會不知所措,到底應該寫在那個事件或時機才能與元件搭配的好,就成了EEP最大的使用障礙。循規蹈矩或對程式開發不太擅長的開發者倒還好,尋求EEP的客服人員往往可以得到可以接受的答案。但是,如果是開發能力較強或主觀性強的開發者,可能就會格格不入,這也是長期以來,EEP不可避免的困擾之一。 

            為了解決以上的問題, 在EEP的jQuery規劃之前,嘗試用新的開發模式來克服此困擾,如圖,為傳統EEP WEB元件的設計概念,中間View的設計頁面是透過元件的包裝,連接上共同的DataSource經過WCF或.Net Remoting向A/P Server的Data Model存取資料。此元件透過屬性設定,在執行階段時來決定Render(產生)相對的JS (JavaScript)與HTML語法。這種方式的好處就是不用管JS的開發與如何自動產生HTML,開發者可以得到蠻高的開發效率;缺點就是,在開發頁面上有自行設計的HTML要如何與元件產生的HTML相配合呢?或是如果產生的HTML或JS不能滿足需求,要如何增加功能來彌補呢?


           因此,在元件化之前,我們先以傳統的Hard-Coding來開發jQuery如何與EEP整合,從頭寫起,也就是說如果在View頁面設計時,完全不用EEP 的元件下,如何只透過jQuery或jQuery組件來存取EEP後端強大的A/P Server資源呢?以下,為EEP jQuery的架構圖,說明如下:

JDataObject.cs:這是一個EEP jQuery的底層框架,此用來連結EEP A/P Server的資料存取元件InfoCommand,資料採用無狀態的方式一次取一個Page(以PacketRecord來定義),資料的回寫(Insert/Update/Delete)則連到UpdateComp來處理,為了符合較新的需求,連線通訊協定改採了WCF架構,也提供了A/P Server上的Server Method(Model端的商業邏輯處理)來讓View可以直接呼叫。

JqDataHandle.ashx:為Infolight.js與JDataObject間的接口,開發者在開發網頁時是以jQuery來呼叫Infolight.js,然後Infolight.js再透過JDataHandle.ashx來執行JDataObject的方法。

Infolight.js:此為EEP jQuery的共用Utility,這裡的JS都是共用的,如提供了寫好的CRUD (Create/Read/Update/Delete)的公用程式,你只要以jQuery的語法呼叫這些程式即可自動反應到後端的A/P Server上,也可選擇是一筆存一次還是一次多筆異動後再一起存檔;為了讓開發者更方便,可以少寫更多的JS,Infolight.js也提供了共用的Default(預設)與Validate(檢核)方案,並可以直接呼叫網頁Code-Behind的C#或VB語法。

           這樣的好處是,你可以自由的以HTML加上jQuery的語法來設計網頁,完全不必受限於EEP的前端元件,又可以享受EEP A/P Server強大的資料處理與管理功能,可以與成熟的EEP Workflow Foundation整合在一起。後面的文章中,我們會刻意以兩種方案來配合使用EEP jQuery的開發方式,一個使用乾淨的jQuery Mobile來開發介面,另一個使用EasyUI的jQuery組件來配合開發,除了前者因為沒有組件所以需要較多的Hard-Coding jQuery之外,後者使用EasyUI幾乎沒有甚麼Code可以寫,都在定義一些參數而已,很多JS的Code都可以被歸納到 Infolight.js。總之,用這種方式,就沒有UI限制的問題,過程中EEP沒有封裝與Render,會按開發者原汁(JS)原味(HTML)去呈現,即所謂戲法人人會變,巧妙各有不同,這就得大家各憑本事囉。

 

EEP的jQuery元件

            其實jQuery並不好學,看似簡單,但學起來沒有1~2個月很難寫出甚麼成就,畢竟EEP的主要精神還是懶人開發工具,就是不想學不想動腦筋。所以,既然jQuery是個潮流,我們除了以上面的架構做好EEP jQuery的框架之外,還是不忘本的要將其包成元件,以屬性與事件的方式來符合多數開發者的習慣。如下圖,我們就以EEP jQuery為核心技術,加上使用現成的EasyUI(目前市面上評價不錯的強大jQuery UI組件)來包裝一組好用的 JQClientTools 元件。

EEP jQuery:就是前面提的JDataObject.cs,JqDataHandle.ashx與Infolight.js 這三個部分,在整體研發的過程是先完成這個核心架構,讓開發者至少可以使用jQuery以Hard-Coding來整合EEP,最後再包裝程元件,目的就是希望其有一個共用核心,當EEP jQuery功能成長之後,元件的功能不至於重複開發,而且也可以簡化元件開發的複雜度。 

JQClientTools:這裡我們包裝的MenuButton,MenuTree(主畫面的元件),JQDataGrid(最重要的表格元件),JQDataForm(表單元件),JQDefault(預設值),JQValidate(檢核條件),JQQuery(查詢元件),在欄位方面,我們提供了TextBox,DateTime,ComboBox,
Refval,CheckBox等最常用的組件。
 

EEP Wizard:強大的EEP Wizard一直是開發者的最愛,有了JQClientTools元件後,EEP Wizard也不例外加入的"jQuery Form"的項目,讓你透過一致的Wizard介面,就可以快速產生已經貼好元件的Web表單,並直接執行成果。

   當然,使用JQClientTools的組件,因為使用動態Render JS與HTML的方式,還是會有自由度與彈性的問題,因此,除了可以在元件的事件加入JS Code來部分解決之外,其實是可以混合EEP jQuery與JQClientTools元件兩種方式混用,這樣就會讓整個開發變得更自由與更有彈性。 

不但如此,這個JQClientTools的元件,也會被整合到我們未來的EEPCloud雲端平台產品,目前Beta版的EEPCloud之Web頁面是使用Dev Express來產生結果,我們將在5月開始改用JQClientTools這組元件,以統一EEPClund與EEP Web頁面的風格呈現,所以,在整個EEP jQuery的研發方案中,真是可謂一劍三雕來形容。 

 

結語

jQuery並不是什麼新技術,或是新科技,2009年被微軟收編與整合到VS2008 SP1時就開始被.NET引用,真正量化使用應該始於VS2010,有點相見恨晚,最可惜的是,2009到2011年三年間大量投入的Silverlight研發,雖最後還是走向放棄之路,但也因為藉著Silverlight強大的UI與拖拉功能及效能反應,造就了EEPCloud的設計器(Designer),畢竟在雲端中設計器與開發環境是最難實現的。 

jQuery只是訊光研發團隊的一小步,後面將會持續投入資源擴充EEP jQuery的功能,務必使Hard Coding的開發者可以用更少的Code來達到目的。另一方面,我們也會持續增加JQClientTools的元件數量,來大幅降低開發者Coding的時機,增加系統的維護能力。同時,往後我們也會整合一組jQuery的Workflow UI介面,供開發者以jQuery來引用Workflow的機制。因此,可以預見的幾年內,這個以HTML5與jQuery為主的技術與潮流,將引領風潮,風華再現,就讓我們持續看下去吧。