一篇对SSH等框架的总结

原文出处： http://bbs.csdn.net/topics/350015249

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