基于Ajax進行Web系統的開發無疑是現在最大的熱點，但畢竟web系統開發這個前提是一樣的，所以在基于ajax開發的時候同樣是request/response模式，只是這個過程是異步的，那來看看基于ajax開發和傳統web開發有什么不同的地方，首先可以看一個典型的ajax的交互場景：
1、web頁面的響應交由對應的js事件進行處理，通常來說這個js需要對web頁面的請求進行分析，提取必要的參數，組成調用service facade所需的格式。
2、js通過dwr、buffalo這些web remoting框架調用后臺的service。
3、Service Facade根據請求進行分發至相應的service進行處理。
4、在service處理完畢后將結果返回至js，這時會有兩種做法，一種是將html在service facade部分進行組裝，將此html返回給js，由js直接負責顯示；另一種做法是返回數據給js，由js負責將數據進行渲染顯示。
在上面的這個交互過程中，對比MVCFramework(webwork、struts)這些會發現基于ajax的交互過程中的一些不足點：
1、web頁面對提交至的js要明確。
2、js需要對請求的參數進行解析形成service facade所需的參數。
3、html在service facade部分進行組裝是否合適？另外一個解決方法則導致需要在js中負責html元素的創建。
先將這三個不足點放在一邊，這個時候我們來看看基于傳統的MVCFramework的一個典型的交互場景：
1、Web頁面的響應交由統一的servlet進行處理。
2、Servlet將請求的參數進行處理，調用相應的ActionFramework由其進行具體的事件處理。
3、ActionFramework調用相應的action進行處理。
4、Action處理完畢后返回result至actionFramework，這時ActionFramework調用相應的resultResolver，結合相應的顯示頁面將顯示的html放入response中。
這是一個比較典型的基于MVCFramework的交互過程，在這個過程中我們得到的幾點好處是：
1、MVCFramework會根據配置將請求分發至對應的action。
2、MVCFramework會根據action所需的參數從request中提取并注入進去，不需要自己從request中去解析。
3、MVCFramework會根據action的執行結果結合相應的頁面進行解析生成html。
現在我們再來看基于ajax開發的三個不足點，發現目前的MVCFramework對其無疑是個解決方案，只是如何將現在的MVCFramework的思想與基于ajax的開發進行結合，這里我們首先看基于MVCFramework交互過程和基于ajax交互過程，會發現這個過程是如此的類似，js可以看成是servlet的替代，相當于給個簡單的理解就是基于servlet的是一種同步的request/response，而基于js的是一種異步的request/response，這個時候其實基于ajax的開發也就同樣的轉入了傳統的基于MVCFramework的一個開發形式，這里面疑問的問題是在服務器端生成html的問題，我倒覺得這個不是問題，象利用velocity等仍然可保證view的純潔性，返回html至js由js負責重寫的方式我覺得比返回數據由js渲染的方式來得好，畢竟在模板文件上寫是一件多么容易的事，和UI可以很簡單的結合，在經過這樣的分析后提出一個這樣的基于ajax的交互過程：
目前的ajax的os的東西好像還不能達到這樣的場景吧，那么其實我們需要做的是對webwork稍做改變，讓其只是接受request，然后的流程和目前webwork中的完全相同，將request封裝為xwork需要的，由xwork負責將其相應的注入到對應的action，action處理完畢后返回結果，由ResultResovler解析為html返回，此時前端的js則將此html進行顯示即可完成整個的交互過程，^_^，maybe下個版本的struts TI會很好的支持這種方式。
在這樣的一種情況下，我們會發現基于ajax的開發對現有的MVCFramework其實不會造成太大的影響，相當于只是加了一種異步的處理模式，可以想像很快MVCFramework都能夠支持同步/異步的處理模式，而且對于開發人員來說是透明的。