MVC系列框架之Struts存在的意义是什么？

这个说得有理

可能是我表述的有问题，应用Strtus场景最多的应该是从JSP中将业务逻辑分离开，您举的两个例子都是针对网站的，或许内网的业务系统中Struts的使用更常见。
对于您的第一个说明：前台就两个页面，这周情况根本就不会用struts，那就不再我们讨论的范围内。

对于第二种情况，一般需要MVC来分离表现与业务。我上文也提过，Struts只能算是一种伪MVC，其实它最主要的就实现了一个C（控制层），其他的都交由其他技术来实现了。但是其控制跳转的实现跟当前的技术发展趋势我觉得是相违背的。Strtus没限制View（视图层）实现，但是考虑到RIA的场景，不管的Ajax、还是Flex方案，获取的数据绝大多数情况下都不是一个页面，而是数据，所以我认为其控制跳转的思路在当前技术发展的情况下是应该考虑被废弃的。

我认为目前的前端技术才开始起步，将来会是一种什么样的情况谁也说不清楚。那么考虑模型层提供数据，而不是页面，将其控制层转移到前端交由前端自行实现（Ajax场景下交由Js绑定事件实现）。将其伪MVC成为真正的MVC实现方案，彻底基于事件控制。这样，不管是对于前端的发展，还是对于后端的业务处理都将变得更加清晰。

存在的都是合理的。培训跟写书等等一样，只是一种传道授业的方式，为什么在您看来会有贬低的意思？
PS:我没有接受过什么培训

ZK框架是这种思路比较好的一个实现，我个人觉得ZK框架更像Flex，前端全部采用自定义的XML来实现了（我并没有使用过ZK，只是大概了解过，可能观点不是很正确）

但还是有很多情况下还是采用传统的html的方式来实现的。从html的编程方式直接跳转到XML的编程方式，对于一个公司来来说，在执行上还是有很大的阻力的，人员的状况，早期的项目都是需要慎重考虑的。

但不可否认，是Struts将MVC的理念深深渗透到了JAVA EE领域的
PS:Java SE的Swing大家就不用拿来讨论的吧

对于改善早期在JSP中业务代码掺杂在表示层中的状况，Struts还是功不可没的

但对于当前技术发展的趋势，其核心思想之一的控制转发，我个人觉得应该需要考虑被废弃，因为现在我们有更加优秀的替代方案。

树木还是森林，不到最后，谁会知道呢？
引用鼬的一句：“只要是人……都是依靠自己的知识、与认识，并且也被之束缚生活着的。 那就叫做现实。 但是，知识和认识是暧昧不清的东西，现实也许只是镜花水月。人，都是活在自己的执念中的…… ”......

其实这里我想表达的意思是作为一个MVC的实现，或者是一个伪实现，Strtus中的控制转发可以用一种更优雅的解决方式来实现。对于可维护性、可扩展性都是有帮助的。
可维护性：不再需要去弄清页面到底是怎么跳转的，现在后台可以更加关注于数据，前台可以专注于客户体验
长期技术方案的可扩展性：一旦前端技术发展了，可以更加简单的迭代更新，顺应业界的技术发展，或许我这个实现思路也不是很好，但是Struts的控制跳转到页面的编程方式是可以考虑被废弃的。

这里大家就不要非要去纠结于Strtus是否是一种MVC实现，大家能明白我的意思就可以了。

既然Struts得总控就是一个Servlet，不能把Struts的mvc理解为Servlet实现的吗？

我做过的web项目不多，但是也用过springMVC、Struts1、Struts2，也有直接是servlet的。

总的老说，我是非常讨厌这些框架的东西的。

毕竟每个框架都有自己的api以及一些规范什么的。

而Servlet本身就足以完成这些任务了。

另外有段时间，曾发现，找Servlet或者其他Java web的相关文档，竟然比找Struts2的文档还难。

同时，发现servlet3标准也是蛮好的。
等到Servlet3流行起来后，这些第三方框架必然是要升级、甚至会有天翻地覆的变化，
而作为用户的我们，恐怕又要经历一次学习的过程。

另外上面有人提到了，MVC的View不一定是表现页面，纯数据（如json）也是view的一种形式啊，真的不应该拘泥于什么什么模式。V，说到底，应该是我们程序的输出口。

我对MVC理解不深刻，一直认为，叫做CMV比较合适。

刚刚看到一个老帖：http://www.iteye.com/topic/11726
我看了收获挺大，哈哈，您有空也看看吧，这个里面提到了Servlet的开销问题，而框架一般只有一些主控Servlet，其他的都是简单JAVA类。

另外，对应一家想长远发展的公司，有自己的一套技术体系比较好，仅为个人观点。