为什么要用ssh
想知道现在的java项目为什么用struts+spring+hibernate，如果要用控制反转为什么不直接用spring mvc+hibernate呢？
另外ssh里面的struts是struts1还是struts2用的比较多？大伙来发表下意见吧！
我只用过struts，请教大家了。
[解决办法]
典型的J2EE三层结构，分为表现层、中间层（业务逻辑层）和数据服务层。三层体系将业务规则、数据访问及合法性校验等工作放在中间层处理。客户端不直接与数据库交互，而是通过组件与中间层建立连接，再由中间层与数据库交互。
表现层是传统的JSP技术，自1999年问世以来，经过多年的发展，其广泛的应用和稳定的表现，为其作为表现层技术打下了坚实的基础。
中间层采用的是流行的Spring+Hibernate，为了将控制层与业务逻辑层分离，又细分为以下几种。
Web层，就是MVC模式里面的“C”（controller），负责控制业务逻辑层与表现层的交互，调用业务逻辑层，并将业务数据返回给表现层作组织表现，该系统的MVC框架采用Struts。
Service层（就是业务逻辑层），负责实现业务逻辑。业务逻辑层以DAO层为基础，通过对DAO组件的正面模式包装，完成系统所要求的业务逻辑。
DAO层，负责与持久化对象交互。该层封装了数据的增、删、查、改的操作。
PO，持久化对象。通过实体关系映射工具将关系型数据库的数据映射成对象，很方便地实现以面向对象方式操作数据库，该系统采用Hibernate作为ORM框架。
Spring的作用贯穿了整个中间层，将Web层、Service层、DAO层及PO无缝整合，其数据服务层用来存放数据。
我现在开始学的是struts1，Strut2是Struts1和webwork 的结合，如果你先学习下struts1那么Strut2就不会感觉难了。。。
[解决办法]
1. 开发效率高。尤其对中小应用。
2. 技术框架较为成熟, 社区支持很好。
3. 层次结构清晰, 由Spring充当组件容器提供统一管理。
4. 耦合小, 很适合因需求变化导致系统频繁改动。
一点拙见~
[解决办法]
总体来说是大家的使用习惯问题，再者，Spring和Struts以及Hibernate的集成做的很好，实现了敏捷开发，加快了项目的进程，同时也避免了不成熟技术造成的项目风险。
[解决办法]
框架的作用就是重构你的代码，如果你用了这些框架，你会发现你的代码维护起来很方便了，很多需求的频繁变更都容易对付了。另外，如果不用ssh，那么你用什么呢？servlet+jsp+jdbc？也不错，不过你能保证你写的代码没有冗余，过若干时间后自己还能记得是怎么架构的？
[解决办法]
楼主 对于这个问题的解答 我觉得
你应该学会使用ssh做项目 再你做过之后自然会明白的
我当初对这些问题也不理解 只有做过才会真正的理解
[解决办法]
SSH 并不好的组合，SSH 有成堆的配置文件，为了接口而硬掰个接口出来了，为了分层而硬把层次分开，在开发效率上来说应该是很低的。
将配置文件与代码分离，将会导致看看代码，再看看配置文件，严重扰乱开发人员的思维。
我一般不喜欢人云亦云，至于为什么 SSH 会那么火，我感觉就是人云亦云的结果，只看到好的一面，没有发掘其不好的一面。
说了那么多 SSH 的坏话，我估计会被口水淹死，呵呵。
不管学习 SSH 或者其他什么也好，对于这些框架学习者我建议走的路线是这样的：
Hibernate 等 ORM 框架之前，应是相当熟悉 JDBC 操作，并且知道一些理论性东西。
使用 JDBC 的时候，是否使用了数据库连接池，如何使用开源的数据库连接池？
JDBC 中的行集（RowSet）是做什么用的？
JDBC 如何实现对象/关系映射，也就是 O/R Mapping。
为什么 JDBC 规范推荐首选从 DataSource 中获得数据库连接对象（JDBC 4.0 Specification, p.51.），
而不是首选从 DriverManager 中获得连接对象？
使用 DriverManager 获得连接对象时，虽然从实现 JDBC 4.0 规范的驱动程序开始，不需要使用
Class.forName("xxx.xxx.xxx.Driver"); 了，但我们也有必要了解一下这句话的作用是什么？
单纯地使用 JDBC 时如何实现低耦合性的事务管理？也就是说事务边界在业务层，一个业务层调用多
个数据库操作的方法完成一个事务，在这种情况下如何进行事务控制？
在使用 Spring 之前，我认为应先掌握：
熟练地使用 JAXP、jdom, dom4j 等工具解析/生成 XML 文件，并能使用 XPath 进行 XML 查找；
掌握 Java 中的反射，以及 JavaBeans 规范中的内省类，了解 JavaBeans 规范对于方法名、属性的要求
（别看这个很简单，实际上很少有人知道）；
了解 JDK 的动态代理和 Cglib 的动态代理，了解 JDK 动态代理的限制，以及与 Cglib 动态代理的优缺点，
并且了解一下动态代理是做什么用的；
熟练地使用日志工具，比如：JDK 日志工具、log4j 工具等，以及在使用时需要注意些什么；
能善于使用开源框架中已经实现的东西，比如 Apache Commons 中很多实用的方法，像实现了 LRU 算法的 Map 等等之类的。
下面是我对一些开源框架的观点：
Spring
优点：IoC、AOP 容器，集大成者，集众框架，可谓包罗万象，应有尽有，学习资料丰富
缺点：极其繁杂的配置文件，原来有个 Spring 的项目，配置文件就有 8000 多行，可以把人看晕掉，极其不喜欢！大事小事都得弄个接口，感觉是为了接口而接口，估计有好多人是先写类再写接口的吧？
Hibernate
优点：ORM 的领头羊，ORM 事实上的标准，功能完善，学习资料丰富
缺点：在效率上有些问题，加之含有许多的 hbm 配置文件强行与代码分隔。
Struts 1.x
优点：老牌 MVC 框架，MVC 事实上的标准
缺点：说实在的我感觉除了比 Servlet 少在 web.xml 中配置一些东西、自动封装 FormBean 之外，没感觉到有什么好处，这个框架最不好用的就是它的标签，除了 html 标签好用之外，其他的标签极其不好用，特别是 logic:iterator 远远没有 c:forEach 用起来舒服。
Struts 2.x/WebWork 没用过。
JBoss Seam
优点：
完全打破三层体系架构，借助于 JSF 采用两层结构，页面层和组件层，Seam 是按照业务逻辑来分层，而不是按照架构来分层。
Seam 的最低版本是在 JDK 1.5 之上设计的，使用了很多 JDK 1.5 的新特性，大量地使用 Annotation，这种方式完全可以取代复杂的配置文件。就算是其中的日志组件也是采用变参实现的，这样我们就不用在页面上写 if(log.isDebugEnabled()) 了。
采用 xhtml 的 JSF 页面，将 JSF 原本的配置分散到每个页面的 .page.xml 文件中，可以在里面写些：进入页面时需要执行的方法、有哪些参数需要传递的、页面如何导航等等。
Seam 拥有完善权限模型，权限不仅可以在页面中表现，也可以通过 Annotation 在方法上限制该方法的执行权限。
Seam 中的 Backing Bean 可以是普通的 Java Bean，也可以是 Session Bean，这样就可以让 Seam 工程不仅能运行在 EJB 容器中，也可以运行在 Servlet 容器中。
Seam 中扩充了 Servlet 中的请求范围，增加了 Conversation、Process，而不是 Servlet 中的 application, session, request, page 四种。最常用的是 Conversation 这表示一个业务逻辑的作用范围，比 Session 小，比 Request 大。这种扩充完全是为了一整步骤的业务逻辑而定制的。
想想看使用 Seam 可以使用 Seam Gen 或者是 JBoss Tools 的 Eclipse 插件产生某个表的增删改查分页功能，如果不涉及业务逻辑，而且使用默认的模板可以一行代码不用写，快速开发，诱人吧 ^_^
缺点：
学习难度相对于 SSH 大很多，学习资料相对较少，其中所使用的 JSF 不用说了，相对于 Hibernate，Seam 所使用的 JPA 也是需要一定阶段地学习才能灵活使用的。其中还有多如牛毛的 Annotation、双向注入、 WebBeans 等概念也是需要一定时间来掌握的。
Seam 中所使用的页面组件框架，比如 Ajax4JSF, RichFaces 等等也是需要一定时间来掌握的。
