欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

{转}SSH思想之我见!

程序员文章站 2022-07-02 17:53:01
...

http://shiyangxt.cnblogs.com


 最近搞了一下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

接口。

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