为什么要用SSH？

楼主问题：

想知道现在的java项目为什么用struts+spring+hibernate，如果要用控制反转为什么不直接用

spring mvc+hibernate呢？

另外ssh里面的struts是struts1还是struts2用的比较多？大伙来发表下意见吧！

#16楼 回答：

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 等等也是需要一定时间来掌握的。

#24楼 回答：

典型的J2EE三层结构，分为表现层、中间层（业务逻辑层）和数据服务层。三层体系将业务规则、数据访问及合法性校验等工作放在中间层处理。客户端不直接与数据库交互，而是通过组件与中间层建立连接，再由中间层与数据库交互。
 表现层  是传统的JSP技术，自1999年问世以来，经过多年的发展，其广泛的应用和稳定的表现，为其作为表现层技术打下了坚实的基础。
中间层  采用的是流行的Spring+Hibernate，为了将控制层与业务逻辑层分离，又细分为以下几种。
Web层  就是MVC模式里面的“C”（controller），负责控制业务逻辑层与表现层的交互，调用业务逻辑层，并将业务数据返回给表现层作组织表现，该系统的MVC框架采用Struts：
Service层  就是业务逻辑层，负责实现业务逻辑。业务逻辑层以DAO层为基础，通过对DAO组件的正面模式包装，完成系统所要求的业务逻辑。
DAO层  负责与持久化对象交互。该层封装了数据的增、删、查、改的操作。
PO  持久化对象。通过实体关系映射工具将关系型数据库的数据映射成对象，很方便地实现以面向对象方式操作数据库，该系统采用Hibernate作为ORM框架。

Spring的作用  贯穿了整个中间层，将Web层、Service层、DAO层及PO无缝整合，其数据服务层用来存放数据。
        一个良好的框架可以让开发人员减轻重新建立解决复杂问题方案的负担和精力；它可以被扩展以进行内部的定制化；并且有强大的用户社区来支持它。框架通常能很好的解决一个问题。然而，你的应用是分层的，可能每一个层都需要各自的框架。仅仅解决UI问题并不意味着你能够很好的将业务逻辑和持久性逻辑和UI 组件很好的耦合。
        不可否认，对于简单的应用，采用ASP或者PHP的开发效率比采用J2EE框架的开发效率要高。甚至有人会觉得：这种分层的结构，比一般采用JSP + Servlet的系统开发效率还要低。

笔者从一下几个角度来阐述这个问题。
—、 开发效率：软件工程是个特殊的行业，不同于传统的工业，例如电器、建筑及汽车等行业。这些行业的产品一旦开发出来，交付用户使用后将很少需要后续的维护。但软件行业不同，软件产品的后期运行维护是个巨大的工程，单纯从前期开发时间上考虑其开发效率是不理智的，也是不公平的。众所周知，对于传统的ASP和 PHP等脚本站点技术，将整个站点的业务逻辑和表现逻辑都混杂在ASP或PHP页面里，从而导致页面的可读性相当差，可维护性非常低。即使需要简单改变页面的按钮，也不得不打开页面文件，冒着破坏系统的风险。但采用严格分层J2EE架构，则可完全避免这个问题。对表现层的修改即使发生错误，也绝对不会将错误扩展到业务逻辑层，更不会影响持久层。因此，采用J2EE分层架构，即使前期的开发效率稍微低一点，但也是值得的。

二、 需求的变更：以笔者多年的开发经验来看，很少有软件产品的需求从一开始就完全是固定的。客户对软件需求，是随着软件开发过程的深入，不断明晰起来的。因此，常常遇到软件开发到一定程度时，由于客户对软件需求发生了变化，使得软件的实现不得不随之改变。当软件实现需要改变时，是否可以尽可能多地保留软件的部分，尽可能少地改变软件的实现，从而满足客户需求的变更？答案是——采用优秀的解耦架构。这种架构就是J2EE的分层架构，在优秀的分层架构里，控制层依赖于业务逻辑层，但绝不与任何具体的业务逻辑组件耦合，只与接口耦合；同样，业务逻辑层依赖于DAO层，也不会与任何具体的DAO组件耦合，而是面向接口编程。采用这种方式的软件实现，即使软件的部分发生改变，其他部分也尽可能不要改变。

注意：即使在传统的硬件行业，也有大量的接口规范。例如PCI接口、显卡或者网卡，只要其遵守PCI的规范，就可以插入主板，与主板通信。至于这块卡内部的实现，不是主板所关心的，这也正是面向接口编程的好处。假如需要提高电脑的性能，需要更新显卡，只要更换另一块PCI接口的显卡，而不是将整台电脑抛弃。如果一台电脑不是采用各种接口组合在一起，而是做成整块，那将意味着即使只需要更新网卡，也要放弃整台电脑。同样，对于软件中的一个个组件，当一个组件需要重构时，尽量不会影响到其他组件。实际上，这是最理想的情况，即使采用目前最优秀的架构，也会有或多或少的影响，这也是软件工程需要努力提高的地方。

技术的更新，系统重构：软件行业的技术更新很快，虽然软件行业的发展不快，但小范围的技术更新特别快。一旦由于客观环境的变化，不得不更换技术时，如何保证系统的改变最小呢？答案还是选择优秀的架构。
在传统的Model 1的程序结构中，只要有一点小的需求发生改变，将意味着放弃整个页面。或者改写。虽然前期的开发速度快，除非可以保证以后永远不会改变应用的结构，否则不要采用Model 1的结构。

采用Hibernate作为持久层技术的最大的好处在于：可以完全以面向对象的方式进行系统分析、系统设计。
 DAO模式需要为每个DAO组件编写DAO接口，同时至少提供一个实现类，根据不同需要，可能有多个实现类。用Spring容器代替DAO工厂

通常情况下，引入接口就不可避免需要引入工厂来负责DAO组件的生成。Spring实现了两种基本模式：单态模式和工厂模式。而使用Spring可以完全避免使用工厂模式，因为Spring就是个功能非常强大的工厂。因此，完全可以让Spring充当DAO工厂。
由Spring充当DAO工厂时，无须程序员自己实现工厂模式，只需要将DAO组件配置在Spring容器中，由ApplicationContext负责管理DAO组件的创建即可。借助于Spring提供的依赖注入，其他组件甚至不用访问工厂，一样可以直接使用DAO实例。

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

缺点：
Taglib是Struts的一大优势，但对于初学者而言，却需要一个持续学习的过程，甚至还会打乱你网页编写的习惯，但是，当你习惯了它时，你会觉得它真的很棒。
Struts将MVC的Controller一分为三，在获得结构更加清晰的同时，也增加了系统的复杂度。
Struts从产生到现在还不到半年，但已逐步越来越多运用于商业软件。虽然它现在还有不少缺点，但它是一种非常优秀的J2EE MVC实现方式，如果你的系统准备采用J2EE MVC架构，那么，不妨考虑一下Struts。

#4楼 

1. 开发效率高。尤其对中小应用。

2. 技术框架较为成熟, 社区支持很好。
3. 层次结构清晰, 由Spring充当组件容器提供统一管理。
4. 耦合小, 很适合因需求变化导致系统频繁改动。
一点拙见

#5楼 

说句老实话，spring的mvc比struts好，struts2比spring的mvc好，底层大概都hibernate了吧。

spring3就不清楚了，那玩意要钱。

#6楼 

总体来说是大家的使用习惯问题，再者，Spring和Struts以及Hibernate的集成做的很好，实现了敏捷开发，加快了项目的进程，同时也避免了不成熟技术造成的项目风险。

#7楼 

比较好维护，扩张，思路也很清晰

#9楼 

框架的作用就是重构你的代码，如果你用了这些框架，你会发现你的代码维护起来很方便了，很多需求的频繁变更都容易对付了。另外，如果不用ssh，那么你用什么呢？servlet+jsp+jdbc？也不错，不过你能保证你写的代码没有冗余，过若干时间后自己还能记得是怎么架构的？

#10楼 

楼主 对于这个问题的解答 我觉得
你应该学会使用ssh做项目 再你做过之后自然会明白的  
我当初对这些问题也不理解 只有做过才会真正的理解

#11楼 

引用 10 楼 yuhonggood 的回复:
顶一下 有些东西只有用了才知道

#12楼

感觉用起来，什么都清晰了

#14楼 

程序设计学习的过程中注重的就是个:实践出"真知"!(真知:真的知道,真的明白!呵呵!)

#15楼 

spring mvc毕竟相对于struts来说是新的，其文档和开发小组的热度都没有struts高，所以其稳定性没有得到充分证明，
如果一个框架没有其开发社区的热情支持很难流行的，另外struts与Spring的整合也完全是把他们的优越性都呈现了，没必要在用spring mvc。

#19楼 

火龙果！说的真好！ssh确实不是那么好！真的感觉是为了接口而接口，我也是先写类再去写接口的那类

#21楼 

虽然SSH结合很好用，但是现在好多公司还是用自己的封装类，因为自己做的封装类在以后维护起来会很方便

#22楼 

看到了，过来学习下。现在用ssh开发的工具做项目，觉得hibernate的效率有待提高。不过编程时的规范也很重要，很多效率都是自己代码问题导致的。

#23楼 

效率吧！！为了开发方便，Struts提供了丰富的标签库，通过标签库可以减少脚本的使用，自定义的标签库可以实现与Model的有效交互，并增加了现实功能。　Spring是一个开源框架，它由Rod Johnson创建。它是为了解决企业应用开发的复杂性而创建的。Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。  
我现在熟悉只有mvc控制模型开发，对于ssh还没研究，对jsp也比较熟悉，自己感觉用mvc模式最好了，尤其对代码的重用性最好

#25楼

为了分工明确

#26楼 

大型项目才用吧,小的就不要了,还会搞得慢

#27楼 

个人认为ssh是众多技术员给吹捧起来的,一般情况下使用spring足以,spring是一个一站式的框架,有自己独立的mvc,全面支持jpa,使用起来比ssh方便而且简单,spring2.5开始全面支持annotation,避免了以前众多的配置文件!

#28楼 

因为ssh大家都会呗.
这样公司代码经过N手开发都没问题了

#30楼 

小的网站就不用，ASP PHP足以
SSH是豪华配置，比较灵活，结构清晰，我最近的一个网站，用了SSH，本来就是大刀小用，但是因为数据库要换，用了不到几小时，成功的移植了数据库，后来前台页面不行，要重新做过一套，但是对于核心的东西都不变，这就是好处，嘿嘿，反正好多好处啦，就是灵活，灵活的东西，控制当然要求也比较高了

#33楼 

没错 就是为了加快开发速度

#34楼 

不懂，但我看很多资料都说是一种框架，你只要写业务的逻辑，操作数据库，和连接数据库，那些框架全部替你搞定了

#35楼 

引用 34 楼 bobo364 的回复:

不懂，但我看很多资料都说是一种框架，你只要写业务的逻辑，操作数据库，和连接数据库，那些框架全部替你搞定了

这才是关键，真正有价值的地方在业务逻辑上，框架就是把精力集中用到开发逻辑上，而不是花在项目本身的建设上，如果有个环境，开发起来只写业务逻辑，那么大大减少了项目的成本。至于怎么提供访问控制，数据库连接，事物管理，日志分析，等等系统级功能，谁方便，先进就用谁。

（整理自：http://topic.csdn.net/u/20090917/21/5ad67fb1-1c6d-4c4a-a578-4b52255bcc56.html?seed=1156869336&r=59913078#r_59913078 感谢他们
）