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不可避免的困擾之一。 

           因此，在元件化之前，我們先以傳統的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為主的技術與潮流，將引領風潮，風華再現，就讓我們持續看下去吧。