Struts到底有哪些致命的缺点?

http://www.javaeye.com/topic/2529

dlee:

1、三层结构包括哪 3 层？
表示层、业务层、集成层。
2、MVC 要解决什么问题？
表示逻辑与业务逻辑分离的问题，就是要把表示层与业务层分开。这个问题重要吗？非常重要。事实上我几年前就在向别人宣传 MVC 和 JSP 开发的 Model2 方式的重要性，还翻译了可能是国内第一份 Struts 使用指南，引起了大家对于这个问题的重视。
3、除了 MVC，这个问题有没有可能用其它方法来解决？
有，而且我们确实很好地解决了这个问题。答案就是 JavaScript+XMLHTTP。把表示层前推到浏览器，将表示层需要的数据通过 XMLHTTP 接口发给浏览器，然后通过定义复杂的映射关系，将这些 XML DOM 中的数据映射到 HTML DOM 的页面控件中。由于涉及到商业机密，我只能说些大体的轮廓，请大家见谅。
4、MVC 没有解决什么问题？
这个问题其实很多朋友都意识到了。最终用户需要什么？表现能力丰富的 Rich Client，MVC 能解决这个问题吗？No，MVC 解决的是另外的问题。那么什么技术能解决这个问题？JavaScript、DHTML、ActiveX、Applet、Flash，etc. 所以 MVC 所解决的问题也只是表示层的一部分问题，而且 MVC 使用起来也不是很方便，比起我们的解决方案总有些笨拙的感觉。



这样一说大家就会很容易发现，表示逻辑与业务逻辑分离，提供 Rich Client 这两个问题的交集就是 JavaScript。这也是我预测 JavaScript 10 年后仍然会存在的原因。因为最终的表示设备是浏览器，怎么可以完全不考虑浏览器的表现能力（脚本处理能力，etc.）而试图完全采用服务器端的手段来解决表示层的问题呢？
所以我们对于 MVC 的使用最终应该归结为这样的问题：我们要解决什么业务问题？这个业务问题除了 MVC 外还有没有其它方法可以解决？与 MVC 相比到底哪个方法复杂性更高？而不是 MVC 本身好不好、重要不重要的问题。

再补充一些我自己的看法。JSP 并不是开发 Web 应用的最佳技术，事实上有很多比 JSP 更好的技术，包括 PHP、ColdFusion 等等。若不是由于后端有强大的 Java 平台的支持，JSP 绝对不会如现在这样流行。正是因为 JSP 本身设计上的缺陷，有人试图解决这些问题，才想到了在 Smalltalk 领域用得很广的 MVC，于是产生了 Model2 开发方式和各种表示层的设计模式。为什么只有 Java 程序员最喜欢谈论 MVC？M$ 平台的程序员则很少谈论 MVC 呢？是不是因为他们确实很弱智，上升不到这样的层次？我可并不这样想。



hellotoy:

本质上说struts还是一个基于jsp的解决方案，所以不可避免的解决不了
jsp最本质的问题。各种逻辑和页面的混乱，解决不了交互性问题，后面再提。
1。tag lib,这是struts最引以为豪的地方，直接的问题有几个，
学习周期长，一端时间不用就会忘记
扩展并不容易，远低于用脚本或者xslt的开发效率，新版的jsp2.0这方面有改进，但是暂时体现不到struts上来。
在页面引入tag以后，其实某种意义上逻辑更加混乱，如果没有好的可视化集成环境的支持，开发效率低、维护成本也高。
我经过1，2年的使用，我觉得tag lib的方案比起类似velocity的模版语言有显著差距，本来引入的目的是为了页面逻辑和表示逻辑，但最后达到的普遍效果是更加混乱。对于美工要求高的页面，美工根本没办法动手。结果我发现，现在很多人用struts，干脆就避免用他的tag,主要使用action来提供控制机制。
还是模版语言，组件方式的做法解决的更干脆。

2。配置文件。
在1.0的时候只支持单个文件，大项目很容易超过几m,协同开发的时候是个灾难。1.1以后可以放置在多个文件，但是一句话，如果没有整合的工具，维护始终是个问题。1.1以后引入的commmon validation,把维护工作进一步增加了。
开发工作中有很多时间都花在解决这些冲突上，所以不得不考虑自己编写教研工具。

3。层面太多，做小应用不适合，远不如jsp+bean的方式简洁快速。
做大应用的话，因为他只是一个表现层的东西，不能单纯的解决问题。
要和复杂的框架结合需要费电功夫，所以还不如直接用别人弄得业务框
架，除非是自己开发平台。

4。和asp.net那种事件驱动机制的前台框架相比，对交互性要求比较高
的应用。开发效率太低了，

至于简单的mvc1，2.谁不会做呀。
这东西的优点就是普及，呵呵。但是我对这类以jsp为核心的解决方案都不感冒。
不少公司以此为标准开发了一些工具，如果能形成统一的技术规范，还有点搞头。