?
?
關(guān)于
MVC
：
?
1、?
Ajax
必然會帶來
Web
開發(fā)
Model2
模型的變革。
a)????????
MVC
的角色由服務(wù)器端向客戶端靠攏，或者，干脆轉(zhuǎn)為其他更合適的形式，
b)???????
V(View)
的角色將不再僅僅是不起眼的
jsp
，在
Web2.0
的時代，它將擁有自己獨(dú)立的一套體系結(jié)構(gòu)。即行為
(Java Script/ECMAScript)
，結(jié)構(gòu)
(XHTML)
和樣式
(CSS)
。
c)???????
M
的角色將更像
DTO
，它的形式可以由多種，比如：
???????????????????????? i.?????????????
字符串
?????????????????????? ii.?????????????
JS
對象
????????????????????? iii.?????????????
應(yīng)用更為廣泛的
XML
對應(yīng)的，他們的傳輸協(xié)議也有多種（當(dāng)然，都是基于
HTTP
）：
???????????????????????? i.?????????????
JSON-RPC
（
JS
對象）
?????????????????????? ii.?????????????
Burlap(
基于
XML
的
Java
對象
)
同時，客戶端
-
服務(wù)器端對象之間的轉(zhuǎn)化也將成為一個必須解決的問題。目前，
JSON
，
Buffalo
已經(jīng)比較好的做到了這一點(diǎn)。
d)???????
C
的角色將更為靠近客戶端，它將利用
Js
的特點(diǎn)，發(fā)揮其快速、靈活的特點(diǎn)。它將取代大部分原服務(wù)器端控制器的作用。從而使服務(wù)器端的編程更加專注與業(yè)務(wù)邏輯。
服務(wù)器端的控制器層則會變得更薄，它將專注于：
????????????????????? iii.?????????????
服務(wù)器端數(shù)據(jù)驗證與安全保護(hù)
???????????????????? iv.?????????????
與業(yè)務(wù)邏輯層之間聯(lián)結(jié)的紐帶
但是，這一層的功能一旦集成到業(yè)務(wù)邏輯層，它將失去主要的作用，很可能退出服務(wù)器端的領(lǐng)域。
?
?
2、?
傳統(tǒng)的
MVC
框架
(
比如
Struts
，
WebWork)
與
Ajax
之間應(yīng)該是競爭的關(guān)系，因為：
a)????????
傳統(tǒng)的
MVC
框架在本質(zhì)上，都是同步調(diào)用，而非
Ajax
提倡的異步調(diào)用。
b)???????
傳統(tǒng)的
MVC
框架試圖用標(biāo)簽來集成一部分
Ajax
應(yīng)用。但這注定只能是一種過渡行為，因為：
???????????????????????? i.?????????????
傳統(tǒng)的
Tag
帶來的不便正逐漸顯現(xiàn)出來。
(
學(xué)習(xí)成本、不利于編輯、客戶端與服務(wù)器端代碼的夾雜等
)
?????????????????????? ii.?????????????
Tag
對
Js
的封裝有限，無法發(fā)揮
Js
強(qiáng)大靈活的功能
????????????????????? iii.?????????????
Tag
是服務(wù)器端生成的代碼，過多的參與客戶端的行為，不利于程序的分層實現(xiàn)。
???????????????????? iv.?????????????
使用
Tag
使得頁面展現(xiàn)邏輯的控制變得復(fù)雜和難于理解。它將使動作與表現(xiàn)的分離變得困難。也使得客戶端與服務(wù)器端邏輯的分離變得不可能。試想用一段代碼來控制一個自己也不知道會不會生成，能生成什么樣
HTML
的
Tag
？
c)???????
基于第一部分提出的原因，
Ajax
所提倡的新的
MVC
方式與傳統(tǒng)的
MVC
框架所實現(xiàn)的方式已經(jīng)有本質(zhì)的區(qū)別，它們之間的競爭也就不可避免了。
3、?
傳統(tǒng)的
MVC
框架適用的地方（
Web Request
適用）：
a)????????
重視
URL
的應(yīng)用，如新聞、論壇等
b)???????
重視搜索引擎優(yōu)化
c)???????
重視用戶傳統(tǒng)習(xí)慣（后退鍵問題等）
實際上，上邊所說的問題
Ajax
都可具有相應(yīng)的解決方案，但是由于并不能顯示出更多的優(yōu)勢。所以傳統(tǒng)的
MVC
應(yīng)用框架仍然有存在的空間。
?
另外，強(qiáng)烈推薦的兩個
PPT
莊表偉：
http://www.ajaxcn.org/space/start/2006-03-13/1/Ajax%E6%8A%80%E6%9C%AF%E5%9C%B0%E5%9B%BE.pps
曹曉剛：
http://www.redsaga.com/down/Use-RIA-And-Metadata-In-J2EE-Enterprise-Dev.ppt
?
這個也不錯，不過沒完全看懂：
http://alex.dojotoolkit.org/wp-content/LowLatencyData.pdf
?
?
關(guān)于用戶體驗：
?
1、?
更佳的用戶體驗是
Ajax
應(yīng)用推廣的原動力
a)????????
2006
年的
Web
開發(fā)將是注重用戶體驗的一年
b)???????
基于異步的
Web Remote
調(diào)用將給用戶帶來更好的用戶體驗
2、?
交互式設(shè)計
a)????????
傳統(tǒng)的設(shè)計令人惱怒，也不能提高生產(chǎn)率
b)???????
基于目標(biāo)導(dǎo)向的交互式設(shè)計
c)???????
http://www.dedream.com
?
關(guān)于
Web
標(biāo)準(zhǔn)和
Web2.0
?
1、?
Ajax
需要建立在
Web
標(biāo)準(zhǔn)之上，因此，學(xué)習(xí)
Ajax
必須學(xué)習(xí)
Web
標(biāo)準(zhǔn)。
2、?
使用
Web
標(biāo)準(zhǔn)能給
Web
應(yīng)用帶來更多的好處
.
。
a)????????
具體的可以參見《網(wǎng)站重構(gòu)》一書。
http://www.china-pub.com/computers/common/info.asp?id=18781
3、?
使用
Ajax
可以實現(xiàn)
Web2.0
的一堆概念
?
關(guān)于
RIA
（胖客戶端）：
1、?
Ajax
是否屬于
RIA
方案？
這種爭論意義不大，但是
Ajax
確實帶來了與其他
RIA
方案相似的用戶體驗。在
RIA
重新引起人們重視的今天。
2、?
比較其他的
RIA
方案，
(Flash\Flex
，
Java Web Start
，
Applet
，
Eclipse Remote
，
ActiveX)
，
Ajax
更容易被
Web
開發(fā)人員所接受
3、?
使用
XML
做
Web Remote
數(shù)據(jù)傳輸體，可以使
Ajax
應(yīng)用方便的遷徙到其他
RIA
方案。
?
其他：
?
挑戰(zhàn)與思考：
1、?
Ajax
推動的困難之一在于開發(fā)人員對
Js
、
CSS
等表現(xiàn)層技術(shù)的輕視。
a)????????
業(yè)界需要
Web
標(biāo)準(zhǔn)、
Web 2.0
等相關(guān)技術(shù)，加強(qiáng)對此的研究工作
b)???????
需要開發(fā)人員重視用戶交互、用戶體驗方面的研究
2、?
相對不成熟的
Ajax
開源框架，目前
Ajax
開發(fā)尚沒有類似
Struts
、
WebWork
等經(jīng)過多年考驗成熟框架，多數(shù)
Ajax
框架還不存在
2.0
以上的發(fā)布版。而且
Ajax
開源框架質(zhì)量的良莠不齊也給開發(fā)人員的選擇帶來困難。
a)????????
部分精品的
Ajax
框架（
DWR
、
Buffalo
、
JSON
等）已經(jīng)將逐步走向成熟，雖然尚缺乏大型應(yīng)用的考驗，但也有了長足的進(jìn)步。
b)???????
國內(nèi)優(yōu)秀的
Ajax
框架
Buffalo
正逐步得到多方面的應(yīng)用。
3、?
Ajax
的安全問題與解決方案，
a)????????
Ajax
使用的
XMLHttp
技術(shù)不能跨域訪問
url,
也不能在
HTTP
協(xié)議的頁面訪問
HTTPS
的請求。
???????????????????????? i.?????????????
對于安全性不高的應(yīng)用，可以使用服務(wù)器端中間頁面（服務(wù)器段代理）解決此問題。
?????????????????????? ii.?????????????
對于確實需要加密的應(yīng)用，可以使用嵌入
HTTPS
協(xié)議的
IFrame
頁面來訪問
HTTPS
請求。
b)???????
DoS
攻擊。
Ajax
使用的
XMLHttp
使用類似
POST
的方式提交數(shù)據(jù)。使得客戶端可以無限制的提交大量攻擊性數(shù)據(jù)。一旦攻擊者采用分布式拒絕服務(wù)攻擊
(DDoS)
，將對系統(tǒng)帶來很大影響。
???????????????????????? i.?????????????
除加強(qiáng)服務(wù)器段驗證外，目前軟件方面無太好的解決辦法。實際上，使用
POST
方式的表單提交同樣存在此問題，但是
Ajax
的應(yīng)用使得服務(wù)器端的服務(wù)地址變得更易被發(fā)現(xiàn)。
?????????????????????? ii.?????????????
使用硬件防火墻。
c)???????
傳輸數(shù)據(jù)減少，使得數(shù)據(jù)被截獲后分析變得容易。
???????????????????????? i.?????????????
使用數(shù)據(jù)加密技術(shù)
?????????????????????? ii.?????????????
使用安全套接字層傳輸數(shù)據(jù)
d)???????
客戶端代碼展現(xiàn)在用戶面前，難以保證商業(yè)項目源代碼的版權(quán)。
???????????????????????? i.?????????????
對
JavaScript
腳本進(jìn)行加密（
Google
）。
?
4、?
其他問題：
a)????????
緩存問題，
XMLHttp
的緩存使得服務(wù)器端數(shù)據(jù)更新后，客戶端不一定能立即展現(xiàn)出來
???????????????????????? i.?????????????
使用隨機(jī)碼訪問服務(wù)器端地址
?????????????????????? ii.?????????????
通過對
XMLHttp
緩存性質(zhì)的設(shè)置，犧牲部分性能來解決此問題
b)???????
瀏覽器兼容性問題：
???????????????????????? i.?????????????
目前流行的
Ajax
框架均可支持大部分的瀏覽器
?????????????????????? ii.?????????????
對于比較古老的瀏覽器（不支持
XMLHttp
）尚沒有解決的辦法，但是使用這部分瀏覽器的訪問者數(shù)量已經(jīng)接近于
0
。