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

根据项目的要求，我得去看Taglib了。郁闷啊~~

Hellotoy讲得很有意思。我原来就是用ASP.NET做开发的，感觉效率上真的不错，而且它的基于组件对象模型，用起来也很爽。不过呢，用JSP，用J2EE的框架做开发确实了解了很多开发的细节，不像Microsoft的那一套，什么都封起来了，都没有了解的空间。

有人说.NET跟J2EE比起来就是不够Powerful，真的是这样的吗？

多谢楼上各位的意见. 尤其是dlee, hellotoy, robbin.  毕竟用这些技术做过项目的体会程度比我这个纸上谈宾还处于失业状态的人要深度刻的多.

总结起来, 感觉Struts的taglib, 页面导航 就象谢逊的七伤拳,  虽然威力无比, 但也会伤其自身. 例如: taglib使页面代码清晰, 通过重用提高开发效率, 但学习周期长,与美工的结合性差, 页面导航它理清了处理过程, 但把controller硬分为三部分, 显然也增加了复杂性, 同时过多的划分与处理也会导致效率上的问题.


我觉得MVC 中的View应是一个广义的概念. 也就是说, 这个View不局限于JSP等某一个实现的方法. 所以象JavaScript, applet等各种实现方法 也可以划在view范围之内.



dlee说得清晰, 直接了当, 再次感谢.



非常同意.



Sorry, 我有点不明白, 页面引入tag后, 真的会更混乱吗? 是不是你们的页面要求特别苛刻?


我几年以前做过ASP的开发,  现在看了一下ASP.NET,  觉得进步不少, 也许在Java世界中这不算什么, 但对M$自身发展应算是进了一大步. 它的Web components给我留下了深刻的印象.  ASP.NET的架构ASP+ Component+ ADO.NET 类使于J SP+JavaBean+ JDBC的结构, 也就是MVC model 1的样子.  应该说是适应小的项目, 但如果项目大了, 我们应也可以把M$中的component 设计成不同职责, 划出 Controller 与 Model,  又何尝不是一种分层清晰的MVC模式呢?

致于Powerful, 不知道是不是指安全性和稳定性方面?

想想我用struts也两年有余了。
Struts的优点不需要我在这边说了。说说他的缺点吧。
struts0.5的时候连upload 都没有。那时候最单纯就是ActionMapping ,ActionForward,ActionForm那时候比较简单的使用action.xml 来管理页面跳转。如果按照dlee的表示层、业务层、集成层。struts集中处理在集成层，表示层交给jsp去实现，当然struts提供了很多的taglib.后面集成了tiles,validate(使用xml作校验不同于Form里面的校验)Struts大致就是这样发展过来的。
其实现在很多的使用还是struts0.5的那些最根本的运用。但Struts争议比较多的在表示层。比如taglib，就我个人的观点，如果项目成员相对稳定的情况下可以考虑使用taglib因为这样前面对taglib的熟练过程产生的学习是比较值得的。如果项目成员流动较大或者项目本身较小最好不要去使用taglib那样很容易把简单的事情复杂化。

另外就是struts 的配置文件struts-config.xml struts的配置文件比较趋向于采用集中化管理（所有的配置在一个文件里面），虽然后面struts支持多个配置文件，但也建议是另外一个颗粒度的集中管理，但很多合成层选用分散的文件配置，比如jpublish 一个页面对应一个配置文件，至于那一种好好像没有定论，但我们以前的确因为struts只用一个配置文件在开发的时候容易冲突。
再有就是struts在显示层比较局限在jsp 所以又如此多的taglib,其实如果可以选择我更喜欢使用velocity,freemark之类的模板方式来处理。

没有你们说的那么复杂,就是id老是传来传去，不爽。最近，想学学tapestry了.

Tapestry在我看来是最接近ASP.NET的一个框架了，所以感觉特别的亲切，呵呵~~~

最接近asp.net的时sofia(salmon),核心的数据访问和绑定就是很传统的基于ms提倡的二维数据表格形式的，这和java世界倡导的数据访问模式有很大差异，可以看那本企业设计模式，martin有专门的论述。sofia和dw配合开发可以接近asp.net的开发效率。
tapestry/sofia 都是UI特征的框架，和jsf是一路的，都是要分离web界面的开发，使web应用的开发和传统的desktop开发一致。但是tapestry的核心是组件和模板，能真正做到ui和代码分离,他和jsf/asp.net的发展思路又是完全不一样的。而sofia和asp.net几乎一致，是以事件驱动+丰富的tag库+绑定的较完善的数据访问机制，缺点就是如果想开发自定义的tag/组件比较困难。jsf好像还没有提供完整的数据访问机制绑定，我认为他也不会做。
webwork/struts则是另外一种思路，叫做fundation 特征的，在TSS上写jsf in action的那个牛人有提。

1.<html:img page="/images/create.gif"  />如果images是一个变量我做成这样，struts不认。<html:img page="/<%=imgPath%>/create.gif"  />
2.<html:img page="/images/goto.gif" onclick="doPage(<bean:write name="form" property="page" filter="true"/>)" 它也不会把page的值给显示出来。
3.有frameset的时候，如果不把各种资源写成绝对路径。可能有时会路径不对把资源给丢了。

1，2不是struts的bug,你可以去查一下jsp tag的spec，人家就是这样要求的。
不过有些app server不应该要求。

以前做项目的时候也想过把xslt放到客户端解析，可惜浏览器不一致，维护多个版本客户端太累。企业内部应用应该可行吧。
有没有人在用TAPESTRY开发？交流交流

其实是不是没有很好的工具支持tag才搞得大家说不好的呢？？
其实DW是支持tag提示的（添加新的tag很方便，可惜不支持tag显示），就是说不用记住那些什么属性了（大概就可以了，就像记API一样）。
js+xml的那种说复杂又不算复杂，但是又是很复杂的东西（要做得好蛮难，如果了解得不是很清楚--例如这个方法是否夸浏览器等，可能会出其它的错都不知道,更可恶的客户端的开发太大，安全性是否有保证），我觉得很难站得住脚，除非你公司本来就有一 套这种解决方案（把一些api都开发好了），其实现在我都会用js+xml解一些显示问题，不过都不敢做得太复杂，其实也是本人的水平太低了。
再说一句，struct/mvc是一个对于美工非常不利的东西（只要是归功于tag），希望大家开发tag时不要太复杂，其实就算是aps.net也是不能解决美工问题。呵呵，不要见怪，好象大家讨论的结果是这样。