SSH思想之我见！

          最近搞了一下SSH，首先是因为SSH还不熟，只是大一暑假时搭建过一次，后来就一直没有搞，暑假那次还是在视频的指导，

和其他人的指点下完成的。原理和思想也不清楚。毕竟当时J2EE刚入门，再加上我们中心的一贯作风，“不求甚解，实现至尚”的原

则。所以一说起SSH，自己就非常心虚。毕竟自己不懂原理，只会搭个壳，也没搞过项目，没有实践的积累。终于在手头的助学网后台

功能全部over而页面一直没有音讯的情况下，抽出了时间把SSH着实巩固了一番。咳~~~还觉得基础还是不够好。一个框架都搞不透。

经过连续几天断断续续的吐血下，终于算是征服了SSH。

******************************************************************

          切入正题，SSH就是struts1.0与Hibernate由spring解耦合。

          SSH分三层，web层（struts），业务逻辑层，数据库操作层（Hibernate）。SSH是J2EE中应用最为广泛的系统级开发框架。

因为它的易于维护和拓展，使得SSH得到广泛的应用。

          SSH的精髓在于spring的管理。

******************************************************************

          常见的SSH层一般分为7层：

          dao层（数据库接口），daoimpl层（数据库操作实现类），vo层（POJO类，数据库实体类），service层（业务逻辑层接口），

serviceimpl层（业务逻辑实现层），action层（web逻辑处理层），form（表单处理层）。

          struts开发项目由来已久，可以说是实现MVC的最早的完善框架。但是技术一直在发展与进步，以至于现在渐渐的已经被更实用的

框架取代，例如struts2（webwook+struts的结合），JSF......之类，这些框架会更好使，更加合理，开发会更easy。但是如果说发展的

成熟度，其实这些新兴框架，也足够完善。起码struts2已经可以很好的开发。从而也就有了我之前的随笔《struts2+spring+Hibernate搭建全解》

。其实前段用哪个框架也不是固定的。

          Hibernate是数据库持久化的框架，是我们从以往的操作数据库转变为操作对象。更利于面向对象编程。而且也对数据库操作进行了封装。

优化了sql语句，异常抛出，开闭连接等等。可以说是非常完善的底层框架。spring对Hibernate注入的操作和方法。也更加方便了操作。但是我并

不主张，让spring过多的注入Hibernate，因为spring的诞生就是解耦的。使web层，与数据库底层操作分离。这样把业务逻辑分离出来。便于扩展

新功能或删除不用的功能，或着移植代码。是在MVC模式把美工（UI设计）和后台编程分离来后的又一大革新。使程序员面向接口编程。把后台的

开发也完美的分离。对于小型的项目来说也许并不意味着什么。但是对于中大型项目来说，节省了大把的开发成本。

          spring就是SSH的画龙点睛之处。spring的精华在于反射机制。偶不得不赞叹

spring的两个核心AOP（面向切面编程），IOC（依赖注入）十分的帅。这两个思想，体现在spring的XML配置文件之中。 其中的依赖注入

是由Bean实现，从而实现面向切面编程，事务的管理。ACEGI（security）（权限验证框架，有待偶的进一步研究）框架中体现就明显。

******************************************************************

废话也不想多说，直接说SSH思想和特点：

1.除了实例化POJO对象需要new对象以外实现impl不再需要new对象，一切都是getBean读取配置文件spring配置文件。

2. 解耦web层与数据库操作层。

3. 利用反射动态获取所有类信息。

4. 对数据库的操作对象化，除了取出单独字段和查询外，尽量使用数据库实例化对象，尽量不使用HQL语句。

******************************************************************

我在刚开始SSH搭建的过程中总是遇到空指针。这就是由于我的思想还停留在struts+Hibernate层面，没有理解SSH的思想。

这样的话，我的这路实现操作与spring根本不同路，而Hibernate又是通过spring配置的。所以当然数据库操作会报空指针的错。

这个困扰我很久。然后就是什么样的分层才是最帅的最合理的。

最终借鉴网上的一些思想和师兄的开发心得，我终于有了自己的实现分层思路。

******************************************************************

最初是打算一个DAO包括所有数据库操作接口。一共20个接口：这套接口是非常成熟且实用的。包括：

增删改查，动态查询，高级搜索，分页实现，动态分页。 这是传说中的BaseDao（当然你也可以叫别的名）。

然后一个BaseDaoImpl实现类。接着是业务逻辑层，和web层。除了这个基类Dao外不再有其他的数据库操作类。

这样业务逻辑层就变得臃肿。其中既有HQL，又有对象的实例化。但是我的想法是本着分离两层，以后功能扩展修改

直接通过修改业务逻辑层一个层和web层。这样就可以少维护一个层。但是后来师兄的心得使我改变了想法。

******************************************************************

师兄的项目是除了BaseDao接口外又新建了其他的数据库操作接口。然后全部实例化操作。让这些子接口继承BaseDao接口，

，但是这样就和我一开始的想法有点冲突。但是实事证明，这样有好处。就是HQL，对象实例化都在DaoImpl里，业务层专注实现

业务，根本不考虑底层操作。也没有乱七八糟的HQL语句。如果修改业务，那么DaoImpl也不用动。毕竟这些方法也不会占几百MB

代码的项目多大地儿。留着呗，说不好以后有用呢。感觉这个方法就是我假期做东西的思路。

******************************************************************

最终我决定使用一个折中的方案，一个BaseDao，多个DaoImpl实现类。因为Dao子接口基本和service层接口一致，所以如果

再写一遍，总觉得是多余。所以就不写了，这套DaoImpl注入BaseDao的实现类方法，并且自己也继承HibernateDaoSupport，

以方便使用泛型或者更灵活的操作数据库对象。一个BaseAction封装并重用getBean等spring与struts的action整合的类。

一个BaseService接口当然也不是必须的，负责业务实现中的对象创建与获取，一个BaseServiceImpl也不是必须的，实例化BaseService

接口。

******************************************************************

这就是我的搭建思路与心得体会。欢迎大家说出自己的想法，交流心得。

 

 转载注明：www.cnblogs.com/shiyangxt

好久没发贴了，以后要多研究东西，与大家分享经验。