分析mvc模式
struts ,經典的mvc模式，認為
view :jsp
control: actionForm/dispathServlet/action
model:ejb或其他業務組件
應該看到，這種分析是相當合理的。但b/s的mvc的特有局限可以更簡化這個模型
從信息流的角度來看
我們有：
page(jsp呈現) ->control->model->control->page
簡單的說：
用戶從頁面發送請求，控制器分析請求調用適當業務方法，用適當的頁面返回信息。事實從來就是這么簡單。
而我不主張有配置文件，實際經驗中，我認為配置增加了學習的難度，降低了學習效率
我們要問：在程序本身就是信息載體的情況下，我們為什么要有配置文件？
我認為有以下是充分的理由：
1。作為容器的整體配置。
2。提煉有共性的東西，不用在代碼中做重復的事情，而且從而便于整體修改。
3。減輕代碼耦合，使得各部分組件化。
考察spring和hibernate，我認為這兩者的配置文件就非常經典。
如spring的
控制bean的生命周期，配置數據庫聯接等，符合1。
自動實現單例模式，提供自動裝配，特別在事務的處理方案上，符合2.
ioc方式，符合3
所以我認為這種配置是非常經典的。
而對于view這邊。我只有一個想法，簡單，再簡單
以上面3個準則為中心，除此的任何配置都是多余的。
考察struts的action配置，非常繁瑣，
我不禁要問,這究竟能解決什么？
唯一可能的就是： 減輕代碼耦合，使得各部分組件化。
但是，為什么view部分要組件化？有什么理由去這么做？因為jsp很難寫，還是action很復雜？這兩者在model2模式中必然配合工作，沒有獨立存在的意義。我想，我們更多的工作浪費在了配置文件和新建無數個action和form上，以及在修改的時候，從jsp找到配置，又從配置找到action,然后找回配置，找回jsp...,讓人傷感的經歷，不是么。
為什么不能直接的從信息流的角度來考慮問題呢。請求，處理，返回。這是多么自然。不要action配置，不要actionForm，應該會更簡單。
不要action配置，是的，我認為不需要。mvc為什么要有這么猥瑣的東西存在呢？看看vc的代碼，看看swing,那個mvc有這么猥瑣的配置文件的存在？何況是被簡化的b/s 的mvc.
view ->jsp , control->servlet/action ,model->spring service
是的，這就夠了
action配置，除了能提供一個不倫不類的站點地圖，能給我們什么？