Struts+Spring+Hibernate学后感

     最近利用时间好好的看了一下SSH，Struts,Spring,Hibernate，并且做了个小项目，我把我个人学习的感觉和理解记了下来，和大家讨论讨论，想来个抛砖引玉，希望大家多多讨论，理解的不对的地方还请直言赐教。

     Struts，负责表示层的，主要玩的就是MVC，主要的就是struts-config.xml配置文件，另外还有标签和验证。主要负责的就是把请求和回复分开，形成层状结构，便于管理。struts-config.xml就是个连线员，而每个jsp页面和每个action，其实就是servlet，就是每台电话，它们就通过它们的“电话号码”——标识符，在连线员的工作下拨通你想要的电话，也就是说跳转到你想要跳转的页面，得到你想要得到的结果页面。

     Hibernate，负责持久层，主要玩的就是ORM，对象/关系数据库映射，配置文件有hibernate.cfg.xml,还有每张表所对应的配置文件，test.hbm.xml,当然文件的名字可以变，只要在web.xml中配置好了就行了。主要是把对象和数据库表给联系起来，再也不用那JDBC直接连接数据库了，也不用重复的写statement.setString(bean.getID())等等了，可以很方便的调用hibernate所提供的方法save(),update(),remove(),find()。当然hibernate也提供了事务的管理等等。如果哪天我们想换个数据库的话，只要把配置文件修改修改，就应该没有什么问题了，而项目中的代码几乎不用重写。对了，hibernate所提供的HQL语言要替代项目中的SQL语句了。

     Spring,负责业务层，说到业务层，就是管理，Spring主要玩的就是“依赖注入”和AOP，配置文件就是applicationContext.xml。它把项目应用注入到框架里，利用AOP的面向方面管理的原理，将整个项目的代码再次分层的管理起来，它提供切入点，通知，工厂模式的机制，很清晰的管理代码。最后我们通过applicationContext.xml的配置内容调用我们所需要的业务service，同时提供事务管理，日志管理，安全管理，异常管理等等。

      我再大胆的“抛砖引玉”一下。在早期，要想用java写web项目，只能拿servlet写，因为servlet写的时候需要调用java的接口，不便于页面的编写，后来就有了jsp,基于html，在html里面嵌套java程序。后来随着项目的增大，请求和回复慢慢变得频繁起来，也就变的混乱起来，因为项目在增大，仅仅靠一个人的能力已经不能满足项目的要求了，需要分工合作，有分工就会有分歧，除非分工很明确。所以，就有这么一天，高手们发明了Struts框架，基于MVC模式，很好的将model,view,controller分成三层，使得请求和回复分开，开发变得清晰。有项目，就会有数据，要不然我们就不需要交互了。那么数据总要有个存储的地方，数据库顾名思义就是个很好的数据存储地方。早期我们就通过JDBC连接数据库，先加载DriverManager,也就是驱动程序，然后获得Connection,再得到StateMent，最后通过执行sql，如果是查询再得到ResultSet结果集。增删改查都要自己写方法，假如一个表的字段有上百个的话，那么我们要插入一条记录需要写多少代码，再如果我们想要使用不同的数据库的时候，我们又需要把多少代码重新编写。出现了这些问题后，又有那么些高人发明了Hibernate框架，从此我们程序员的生活变的美好了许多。可是web项目是越来越大，编写的代码越来越多，也慢慢的就变得混乱了，常常是修改了一处的代码而引发许多出的错误，使得我们程序员的生活又变的不那么美好了，这时候，高人又发明了Spring框架，Spring有效的将Struts和Hibernate集成起来，统一管理，使得整个web项目层次分明，而各个层次之间又是相互独立，假如哪一个模块变动了，我们需要的只是把配置文件里的配置项修改修改就可以了。真正的“高内聚，松耦合”，也就是面向对象编程的思想。

      所以，我们在开发项目的时候，可以使用这些框架，也可以不使用，照样也能完成项目的开发，所谓“条条道路通北京”嘛。框架只是给我们提供了方便，提高了项目的复用性，提高了项目的质量。

      以上就是我的学后感，希望得到大家的高见，共同学习，共同进步。

我觉的框架更多的是给我一个开发的思想，  毕竟许多框架都是不标准的，不标准就是带来的不稳定性。

我还是跟喜欢 标准的东西，JSF和EJB

说的也是，其实我下一步就打算学习EJB和JSF了。

SSH存在的一个最基本的前提就是:前台是一个哑终端,啥能力也没有,只能负责解释一个页面,别的啥也干不了.
举例来说,就拿struts来说,它配置了一个请求,如何转发给后面的Action,最后再返回那个jsp.
其实完全可以在前台直接调用后台的java逻辑,DWR干的就是这件事情,调用完了直接把页面跳过去就行.
至于hibernate,做的是ORM的事情,其实ORM这东西完全可以用javascript来做,在前台来运行,必须放在后面的服务器上,解决并发,资源冲突等问题,又何必呢.
至于spring,它要解决的问题和方案,能不能用js来做,这个需要进一步的探讨.

如果能用js来写一个java的解释器,直接把原代码在javascript里面运行,这些所有的框架就都能在javascript里面运行了.

SSH这样组合还是非常流行的。我是有些不大喜欢这样组合。觉得太多了，而且有些繁琐。

记得07年，50个人的项目，使用SSH。同步代码、AOP注入都累个半死。有的team存在aop那些bean配置文件不对。一个引用另一个，天哪。

后来，我还写了一个工具类：输入一个bean，然后自动的将需要的最小bean写到spring.xml文件里面。这样方便我快速测试。

不过，这个工具类我没用保留。。。  对于SSH我太害怕了

-------------
欢迎大家来“权限管理”圈子做客。
http://accessmanager.group.iteye.com/

标准是人为制定的，别跟公理混淆了。Spring不也已经进驻JCP了么，只要受众群大，无论从商业角度还是从成本角度，好的东西即便现在还不是标准，过不了多久也会成为标准。框架的作用不是给你看他的思想，相反的，是要把这些思想隐藏起来，让你在不熟悉设计模式、不熟悉良好oo的情况下也能简单的写出稳定成熟的代码。EJB和JSF好像都半死不活的吧...-_-|||

看来这位仁兄是个js高手啊，其实这些框架能成为流行，必然存在人家的道理，框架虽说是多了些，可是使得每个层面松耦合了啊，就凭这个松耦合我想js就应该解决的不好了吧。其实框架可以用也可以不用，是由项目决定的。

说的也是，配置文件多了，也是需要管理，不知道下面会不会出来一个什么东东来，管理配置文件呢，你要是把你发明的那个测试的工具发表出来，也许会得到大家的关注呢，成为下一个技术也说不定呢。希望有好的东西出来。

那个东东思路不难啊。

比如我输入beanId是“myBean"， "myBean"引用了"yourBean"，"hisBean"，那么就把这两个也加进来。然后解析加进来的bean即可。

没用什么的。

XML，XML，很多东西好。但不能滥。。。

目前正在做个小项目，虽说没有真正的商业价值，但是还是喜欢做一做。