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