Struts不能完全用MVC来理解

刚才有一个关于Struts和MVC组件对应关系的帖子，现在好像被放入了新手区，关于这个问题记得以前有过激烈的讨论，可惜刚才我搜索一下没有找到想找的那篇，希望有谁找到能把链接发上来

对于这个问题我觉得还是有讨论的一些必要，因为疑惑的人还是存在，而且从我个人来说对这个问题的理解也在不断的变化。现在把我现在的理解写下来，可能存在偏颇（本来理解也在变化），只供讨论

我现在的观点是：
MVC可以帮助刚刚进入面向对象设计的开发者理解分层体系结构（MVC的最大价值），之后在面对Struts，Spring时，可以借助那种分层思想、及各层的大致组件角色和职责对这些框架进行理解，但不必钉钉铆铆的去对应，因为这种对应是模糊的、是非对称的
理由如下

第一
MVC是80年代Smalltalk80引入的一种用户界面应用程序设计模型，经过二十多年的发展，到现在Struts、Spring这些框架已经对MVC进行了很大的（局部）扩展，增加了很多原来不存在的角色，以使其分工更加细致。
以Struts为例，Struts其实只是体现MVC思想的Web层框架，只体现了View和“泛Controller”含义，而对于Model实现规定很少，基本可以自由实现。
这其中最有争议的是Action属于Controller还是Model，我觉得如果非要给Action找个归宿的话，就要看系统设计的具体情况，要看让Action来做什么，如果只让Action来根据请求调用相应的业务服务/处理对象，并将处理结果放入Request Attribute中，那么就可以将Action和ActionServlet、RequestProcessor统统作为“泛Controller”的组成部分（这种纯度高的设计层次较多较细，实际使用不多）；如果让Action来承担一些业务逻辑的处理，比如一次请求需要调用多个业务服务的多个处理，再比如对于简单的设计Action直接调用DAO进行操作，那么它就又具有Model的部分职能，所以一般情况下Action是一个介于Controller和Model的衔接角色。

第二
原始MVC所存在的Smalltalk用户界面应用程序，与Struts、Spring的Web应用程序体系结构不同。在用户界面应用程序中，View和Model之间交互是基于事件的，Controller是作为一种策略Strategy模式应用的，控制不同的事件产生不同的相应方式；而在Web应用程序中，View和业务服务是基于请求/响应机制的，而Action更普遍的认同是作为一个Command模式。

个人理解，欢迎拍砖