SSH思想之我见!

  1. 云栖社区>
  2. 博客>
  3. 正文

SSH思想之我见!

文艺小青年 2017-11-13 17:08:00 浏览1159
展开阅读全文

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

接口。


本文转自施杨博客园博客,原文链接:http://www.cnblogs.com/shiyangxt/archive/2008/11/27/1341818.html,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
文艺小青年
+ 关注