ssh优缺点

spring的mvc，使用起来学习曲线比较高，使用成本也高，struts的一个优点是稳定性好，经过这么多人的使用，经住了环境的考验。

我猜面试官肯定是想说，Hibernate不支持存储过程，而JDBC可以

前段时间无聊, 有个超级小的项目后台狠狠心,重新收拾了一下hibernate,
用hibernate来做底层的DAO层.没有深入去研究,感觉是好不习惯..底层全部给我封装了.现在又丢掉了..还是直接jdbc来的快.以后优化也方便..

PS:个人感觉啊,象企业应用级之类的,这种业务非常多的情况,采用框架(无论是开源还是自作的)
可以很好的统一大规模人员的代码水平和风格.同时可以更方便让高层架构师来掌控全局体系.这是一个最大的有点.从管理上来讲的话.
如果是互联网应用之类的,一般来讲的话,其业务逻辑都不会非常庞大,这种毕竟注重性能极限的情况下,我觉得用不用框架都无所谓了.个人还比较倾向于不用,而从整体和细节上进行性能优化.

SSH所谓的缺点，只不过都是理论上的东西，实际上用起来，绝对的经典！
一个公司，自始至终的用SSH，不存在维护困难，也就不存在侵入性，哪个SB用了一个框架，开发了几个月还去换别的框架
那些说SSH框架有有缺点的，你要是真的精通了，我说你也不会这么认为
就中国现在的那些系统，用SSH算是奢侈了

如果我没记错的话 2.x的确是不支持 3.x可以了;

不直接支持，可以通过自己写ClassPersister来实现，理论上说没有直接用JDBC方便;

的确ssh用起来挺顺手的
至于为什么总结
也是面试被问到,个人感觉回答的不够好...所以回来亡羊补牢...
至于为什么发帖
也是认为一个人不能想到方方面面...


很多人谈侵入性更多的是考虑能不能方便优雅的进行单元测试
毕竟struts1和Webwork还是很鲜明的......

至于开发几个月换别的框架确实比较扯....

struts1.x最大的问题是难于测试，以及和spring的集成方式，他自带的那些个插件机制是出了名的BUG多，而且一定要继承他的Action，formbean也要继承...侵入非常严重,action亦不是线程安全，使用ajax不太方便，视图本身只支持JSP，通过plugin机制扩展...很不爽
Hibernate 有点是ORM，面向对象方式开放数据库，有OO的思想即可各种操作，避免了各种开放效率高之后通过注解，多种底层事务管理机制以及一些代码生成工具，同时也兼容了JDBC，基本上JDBC可以做，Hibernate就可以做，而且方便的提供了缓存管理机制，最方便的还是通过结合Spring进行声明式的事务管理了。缺点可能是设计太过于复杂，学习曲线比较堵，对于过于复杂的SQL显得力不从心
Spring 的IOC容器是一大亮点，可以通过一个或者多个配置文件方便管理bean的生命周期，通过DI在应用程序上下文启动时注入依赖关系 低侵入的设计，AOP则主要用来事务管理和日志，提供了一个设计良好的MVC框架与自身集成非常良好，另外还有测试 webflow等等等等 。总之Spring海纳百川，从持久层到表现层甚至webservice标准提供了支持和对多种框架的封装，使得API更加统一和易用，缺点还是JAVA框架的通病----大项目时，即使拆分处理，配置文件仍然过于庞大不易于管理

对ssh一直持谨慎态度，虽然公司的项目都是基于它开发的，我每次总是能躲就躲得。这次看了LZ的介绍，还是见识很多，因为我每次碰到这些问题，都得去问人，被人的人虽说是在研究ssh，结果证明也是个二把刀选手。这个体系，知识点还是很多的。

另外，看过很多人关于新手、老手的争论，我想说的是：苛刻的人还是歇歇吧，你们像楼主如此年轻的时候，未必有如此的见识。

如果要论讨什么框架的组合，不如来一个实际的场景或者需求，再让大家来讨论，用什么架构是最合适的。
比如简单点的：
CMS系统需求：
1。跨数据库
2。模板引擎
3。页面静态化
4。插件机制
6。统一站点管理（二级站点等等）
。。。。

可选架构：
ssh  s2sh  jsf2.0+ejb3 grails rails play! jboss-seam 。。。。 以及php的一些解决方案。
 

action线程不安全也算是缺点么。。。