Web應用程式發展至今,已經好幾個年頭,從最初的網頁、CGI,到現在我們用ASP、ASP.NET、PHP、JSP,現在越來越多的工具可以幫助我們建構一個可以在網際網路上執行的應用程式。
不過,我們究竟是在開發應用程式,還是網頁?這依舊是一個很耐人尋味的話題…怎麼說呢?打從一開始,網際網路上設計要呈現的是文件,而不是程式,因為要呈現的是文件,所以本來是沒有設計任何程式化的功能在裡面的。
每一個顯示的頁面都是單純的HTML,頁面和頁面之間透過HyperLink彼此相連,這是WWW上面最原始的假設,就這樣,沒別的了。
但是顯然很多人覺得不夠用,因為這樣的網頁不能互動,所以慢慢的,我們有了ASP、ASP.NET。從ASP的出現,已經可以帶給我們相當大的幫助,透過IIS和在IIS上面執行的ASP程式,我們可以和使用者互動,網頁慢慢不只是網頁,開始可以以程式的面貌出現,而ASP大幅的降低了開發一個可以在internet上面執行的程式的難度,從這時候開始,Web應用程式雨後春筍般的出現。
從早期的Windows應用程式,時至今日,好像只剩下Web應用程式才是顯學,特別是在一些基本的應用上(不需要大量的運算,或是複雜的後端邏輯處理…),Web Solutions好像變成唯一的選擇?
Web應用程式有著幾個很大的利基,例如:
- 不需要在使用者端安裝,使用者只要能上網就能執行(現在誰不能上網?)
- 程式更新的時候使用者端也不需要更新
- 使用者端只需要瀏覽器就可以操作(因此可以跨平台,不管Client端是什麼機器,都可以執行…)
但是,這不是表示所有事情都這麼一帆風順…
1-1-2 Web應用程式的問題
發展至今,Web應用程式依舊有著自己本身的問題,如同所有事情一樣,缺點多半是因著優點同時出現的,諸如:
- 無法控制Client端的資源(因為安全性的理由,沒有在使用者端安裝任何ActiveX或是JavaApplet的Web應用程式,無法存取到使用者端的資源,諸如印表機、讀卡機、硬碟…等)
- 互動時候必須換頁(在ASP.ET我們稱為Postback),導致使用ASP.NET建構的大型Web應用程式,當頁面上的控制項很多的時候(表示網頁本身的HTML碼就很大),Postback簡直是可怕的惡夢。
- 受制於頻寬,如果頻寬不足,Postback時不只是惡夢,對客戶來說簡直是一種罪惡。(按下某個鈕,要等個一兩秒畫面才會出現,有時候還會TimeOut)
- Client端的事件和錯誤處理無法輕易捕捉。(因為Client端只有瀏覽器,沒有任何其他的程式在處理)
也因此,除非我們寫了很多的Client端JavaScript(或jQuery),否則Client端的這些問題,始終是Web應用程式開發人員心中永遠的痛…
而這些問題,ASP.NET 2.0提供了很多相對的解決方案。
Note: |
ASP.NET 4.0之後,則提供了更多的功能,不過由於大多是企業級用戶的功能,我們會併入後面的介紹中一起討論。 |
[next]
沒有留言:
張貼留言