注:如果你所在公司的開發環境或者項目的開發環境處于單一語言的開發環境之中,框架不適用,因為框架的使用范圍之一就是針對一個項目中存在多個語言開發的業務模塊,而新項目都需要這些模塊的功能,按照以前的習慣,肯定是重新開發,至少也是將其他的語言開發的業務功能變成webservice接口供新代碼調用,在這種情況下,本文討論的框架就可以派上用場并且還能在客戶端消除語言差異,只使用純javascript和html靜態代碼進行開發。
當然即使在單一的語言環境下,仍然可以使用該模型進行開發,不過開發人員就無法享受到各種優秀的服務端控件(Asp.net控件,專門為java開發的控件等等),只能使用純javascript控件,這會對開發人員造成不方便(特別是依賴服務端控件的開發人員尤其如此)。
經過以上兩篇博文的談論,我們發現這種模型是完全有用武之地的,它將服務端的語言徹底和客戶端分離,開發客戶端的人員(在理論條件下)可以完全忽略服務端的語言種類,只進行純Javascript開發,利用JQUERY中提供的AJAX方法同服務端方法通信。開篇博文:(http://www.vxbq.cn/a/view/11986.html)
從上面的整體架構圖,我們看出:其客戶端都是WebService接口來獲取數據和傳送數據的,而服務端業務模型是什么語言開發的,完全不需要關注(當然在現實情況下,一般WebService接口最好同服務端業務模型是一個語言開發的)。
這個時候可以會首先想到效率的問題:
眾所周知,WebService接口的效率較慢,那么這樣搞是不是會讓采用這種結構模型開發的網站速度變慢,與其這樣,還不如采用常規的方法開發,不僅熟悉而且速度也不錯呢?
先看下面幾個推論:
1)WebService接口的效率慢 <---> 異步獲取數據 ,兩者互相能夠抵消嗎?
2)客戶端采用Post的方式,可以減少數據的量,能部分抵消WebService接口的效率慢嗎?
以上兩個推論,雖然我們沒完全做過對比,但可以肯定的說,它們是有對沖效率的,WebService慢,反映在頁面端無怪乎就是頁面等待長時間不出來,造成用戶體驗下降,但因為采用異步獲取的方式,這種情況還會出現嗎?應該不會。
在傳送過程中,采用Post方式,數據量大大減少,又采用了異步方式,實際運行效果應該是相當不錯的。
但對于某些特殊情況并且有很普遍的問題,比如Table表格的分頁情況,我們又該怎么處理呢?
Table表格數據填充和分頁 這個在頁面上非常普遍的問題確對以上的推論造成了威脅,究其原因就是因為一般的分頁代碼都是把數據返回到客戶端內存中,然后進行分頁,因此大量的數據從服務端傳遞到客戶端,必然造成問題,其實這個問題不僅僅是這個框架的問題,所有采用這種方式進行分頁的代碼都存在這樣的問題,只不過這個框架采用WebService接口與客戶端通信,才導致這個問題的重要性被無限放大了。
以下我們就來討論在這種框架下進行分頁的處理:
環境:Visual studio 2005
JQuery 1.3.2
SQLServer2005
分頁原理:
從上圖中,看到不管數據表中有多少數據,每次返回到客戶端的數據都是一頁的數據,這種方法沒有采用存儲過程方式,而是在webservice端進行處理的。
上一篇 宣傳才是王道 網站推廣技巧大匯總