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

出处 (www.cjea.org)Colin

Struts优缺点
优点：
Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。
除此之外，Struts的优点主要集中体现在两个方面：Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提高开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。
关于页面导航，我认为那将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。
缺点：
Taglib是Struts的一大优势，但对于初学者而言，却需要一个持续学习的过程，甚至还会打乱你网页编写的习惯，但是，当你习惯了它时，你会觉得它真的很棒。
Struts将MVC的Controller一分为三，在获得结构更加清晰的同时，也增加了系统的复杂度。



Struts项目实施经验
前段时间，我们基于Struts架构（结合Tiles），开发了一个WEB应用。以下是我们在项目过程中积累的一些经验和吸取的教训，望对各位有所帮助。
1、 基于Struts架构的项目开发，首先需要有一个很好的整体规划，整个系统中包括哪几个模块，每个模块各需要多少FormBean和ActionBean等，而且最好有专人负责Struts-config.xml的管理。开发基于Struts的项目的难点在于配置管理，尤其是对Struts-config.xml的管理。
2、 如果你的项目非常紧，并且项目组中又没有富有经验的Struts开发人员，建议不要冒然采用Struts。Struts的掌握需要一个过程，对于一个熟练的JSP程序员，自学大概需要半个月左右的时间。如果结合titls，则需要更长的时间。
3、 如果你在网页中大量运用taglib，那么你的美工将做出部分牺牲。当你结合Tiles，功能增强的同时，这种牺牲尤为明显。当然，你对功能和美观的取舍由你自己决定。
4、 Taglib是一个好东西，但灵活运用它却需要一个过程，如果你不想在Taglib上花太多的时间，那么只需理解与FORM有关的几个标记，其它的标记就放着吧，以后再看，先去研究ActionServlet和Struts-config.xml，你会觉得很有成就感。
5、 Struts的诞生时间虽不长，但与之相关的工具却越来越多，如果你是用Jbuilder作为开发工具，那我可以为你推荐几款优秀的open tools，极大的提高开发效率。
6、 Struts是否只适合于大型项目呢？No！Struts适合于各种大小的项目，当然，对于大型项目，它所体现出来的优势更加明显。

总结
Struts是一种优秀的J2EE MVC架构方式。它利用taglib获得可重用代码和抽象 Java 代码，利用ActionServlet配合Struts-config.xml实现对整个系统导航。增强了开发人员对系统的整体把握，提高了系统的可维护性和可扩充性。

我没有struts做过项目, 但以前做项目时也是一种MVC的模式. jsp/servlet/JavaBean/JDBC
jsp/JavaBean/EJB1.1
jsp/servelet/EJB1.1

正因为没有struts的项目开发经验, 所以我不能列举出 Struts 一些致命的缺点, 这个问题困惑我有一段时间了,  希望大家谈谈struts的特点(尤其是缺点)

另外, 记得dlee 说过 MVC也不是万能的,  但MVC做为一种成熟的开发分层的模式, 历经20多年的历史, 它是成功的, 它的缺点又在哪里? 如果有的话, 那么更好开发分层结构应用程序的模式是什么?

致命缺点我说不来，只是有些使用过程中的印象：

1、ActionServlet的执行效率似乎不太好

通过跟踪，发现ActionServlet执行时间占主要的执行时间，例如推荐使用Spotlight for WLS来监测一下在WLS上的执行情况。

2、DW这些工具是不支持Taglib的，会造成一个taglib多的页面，DW打开一看，支离破碎。

3、Tag执行的效率也比较低下。

比较想尝试一下webwork2，只不过没有时间。

Struts多少会有些缺点，但不足以致命。

呵呵，我的意思确切地描述一下。
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 呢？是不是因为他们确实很弱智，上升不到这样的层次？我可并不这样想。

本质上说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为核心的解决方案都不感冒。
不少公司以此为标准开发了一些工具，如果能形成统一的技术规范，还有点搞头。

忽然想到一个相关的问题，为什么现在没有人设想把xsl文件下载到本地的方法呢？这样是不是也是一种Rich Client呢？既然activeX可以java也可以，为什么呢？没有试过，空想而已。

关于 XSLT，我略微有些发言权，因为 XML 的东西我以前研究过很多，而且 XSLT 开发我们公司以前有过一些不成功的经验。
XSLT 的问题是复杂性，没有很好的集成开发环境（达到所见即所得的效果）的支持，很难开发复杂的页面。用 XML+XSLT 做的页面想要达到与 HTML+CSS 相同的效果，工作量要大得多。Dreamweaver 已经可以很好地支持 CSS，而且熟悉 HTML+CSS 的人非常多，用 XML+XSLT 还要重新培养人。所以从成本上考虑，HTML+CSS 仍然是实现表示层的主要技术。
有些唯技术论者（ozzzzzz 兄别介意，我没有特指，只是以前遇到过这样的人）往往知道了 XML+XSLT 后认为 HTML+CSS 显然是已经过时的落后技术，什么开发都应该用第一种方式来做，这是一个错误。连 W3C 都不认为 XML+XSLT 肯定会取代 HTML+CSS，将来 B/S 结构的表示层开发的主角仍然是 HTML+CSS。当然 HTML 可能会逐渐被 XHTML 代替，但是这是另外的问题。

针对 hellotoy 所提供的意见，以前我在研究过 Model1 和 Model2 之后得出的结论是不是所有的应用都需要用 Model2 方式来做开发的，在大量的场合，Model1（JSP+JavaBean/HelperClass）的方式才是首选的开发方式。但是如果用某种框架来做开发，它限制你只能采用 Model2 的方式做开发，这显然是错误的。

xslt我也有点点项目经验，贡献一把，以前做的一个系统，最后输出页面是用xslt来合成，这些东西由一个html熟手来做，我只是稍加指导。我影响当中好像要比比他学struts的那堆tag要进度快很多。而且可以重用的东西比较多容易控制。不过如果运行时动态输出页面的话主要是性能。如果在客户端合成会好些。
我对xslt的关注还是以前写tag写的一团怒水的时候，看到cocoon的xsp方案。
觉得比起tag简单易学。对了现在resin支持的是不是xsp?
说真的，在我成为一个很熟练的tag工人以后，我对tag的开发效率是很郁闷的。
远没有velocity那样的模版语言自有，高效。而且维护更麻烦，几个月以后，谁还记得那些属性，特征。而且页面里面往往很难用直接用tag做一些简单的事，
还是要写脚本。比如对一个页面里任意一条记录的删除确定. 你要给javascript
传一个名字，好啦，问题来了，坚持用tag，就会来段难堪的东西。tag本身也是在破坏页面结构。 干吗要我分解页面，加些所谓的标准进取？velocity对他用模版有个很好的解释，就是这个原因。
还有tag在各个应用服务器上的兼容性问题
比如
<xxx/>
<xxx></xxx>
weblogic 8.1 第一种写法在某型情况有问题，还等到他发布了补丁以后才解决
tomcat检验不够严，一些tag的写法，到了其他app上跑不起来。mmd

在我最早开始吃这碗饭的时候是asp/php,做了几年java以后发现这个模式那个模式，结果开发效率月来月低了。
我自己局的m1适合小的应用，m2规模比较大的项目，能承受高成本，可以同
过这个格式把不同的开发人员区分出来，是建立在分工的基础上，否则如果一个人要做几件活，这个分工带来的效率就没戏了，其实更多时理论。ms就认为asp.net的mvc方式比m2好，简单呀，呵呵。

请问一下,这个需要对浏览器有所限制吗?