分析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配置，除了能提供一个不伦不类的站点地图，能给我们什么？