Struts+Hibernate+Spring运用整理(一)

     Struts、Hibernate、Spring在整个2006年已经不再是什么领人陌生的技术了，去年年初在项目中就有幸使用过。今年刚做完的项目中需要使用到这三者，而我正好我复杂项目的技术框架的制定和全局设计的工作，终于可以全面的彻底的通过项目，将这几个家伙了解一次了。
     由于这个项目的组员都来自各大高校 ，所以项目管理和技术培训成了一大最大难题。
     经过1个半的培训，这些小伙子具备了运用这三项技术进行开发的基本能力。因为再好的技术，如果不给开发者一正确的引导和培训，可能会将项目带向失败的方向。
    回到主题吧，想来看看Struts。这可以说是S.H.S技术中，被关注时间最长的了，其为WEB开发提供一套非常稳定且较为灵活的机制。
    使用了前端控制器+应用控制器+命令对象模式，通过Java的反射机制让框架能够在不同运行情况下通过编辑其持有的config.xml的文件配置来实现对不同业务处理的要求，本人也在业余时间按其原理和架构思想，编写了一个类似的运用小框架(开源项目应该是学习的开始，而非运用的终点)。不过很感兴趣被Struts2的技术实现，在struts和webWork的基础上做了哪些更好的处理
    那S.H.S中的H ---- Hibernate在2005-2006年中Java世界中持久层解决方案的红人，Hibernate中的一些对持久层处理的先进思想也影响到了未来EJB3中对EntityBean(明年的组件热中，EJB3恐怕会成为受人追捧的角色)。Hibernate对ORM思想进行全面且充分的展示和论证。通过Hibernate所持有的API，将Java与特定数据库操作平台的处理细节完全屏蔽在它强大的处理和简单的操作接口下，并且通过Java反射机制实现了将数据库中的关系表和各个表的复杂关联关系通过xml文档描述由Java类的方式按面向对象的思想进行展示。这样使得在开发java程序的时候，完全可以用面向对象的思想理解和完成所有系统中所需要进行的操作。
   最后则是功能最强大的Spring,它的出现使得的“轻量级”这个词一时间成了Java企业级开发中最热门的词典。其所基于IOC思想提供的各种解决方案也使得，在不使用J2EE标准技术的那些自由定义Bean的Java开发程序员找到了一个很好的开发和展示平台(也使得Java企业级开发与传统评价中"笨重"、"复杂"、"缺乏灵活"这些词语说再见了)，更进一步展示了和提升了Java的与运行环境无关，与平台无关的移植性。
   开场白说完，开始介绍项目中的一些感受吧：
   先从结构开始：
   1、在项目开发中，我们喜欢将各个业务实现，以模块来划分，但正如实体划分中会出现的"粒度"问题，如果将模块定义的过细，则有可能会带项目的开发和管理带来一些负担和麻烦。如：将一个很普通的的新闻发布管理进行细粒度划分的话，则可以划分出"添加新闻信息"、"修改新闻信息"、"删除新闻信息"、"浏览新闻信息"，显然这样处理是不正确的。从更准确的定义上这些应该都是处于"新闻管理模块"下的功能块。而且如果按这种思路走的话，需要为其准备多个业务处理的请求对象和业务代理(在Struts中由Action来实现)，这样需要管理和操作的类便异常的多。
          但不是这样分，将"新闻管理"看成一个业务模块，而其他的操作看成它所需要提供的"业务功能",这样在Service层的定义和Action层的定义上则合理清晰了。在具体实现的时候将Action扩展DispatchAction类，这样自定义的处理新闻管理的Action可以提供出多个类似与Excecute方法的自定义方法，根据前面提到的"添加"、"删除"、"修改"等"业务功能"提供了多个处理不同业务功能要求的处理方法。
    感受一：由于多种不同的业务功能的处理需要关注页面上不同的业务请求数据，所以按Struts的标准做法，需要提供多个ActionForm，但Action的一个配置元素<action path=""/>只能配置一个ActionForm与其对应.于是必须按业务处理要求将自定义的Action类给出多个<action path=""/>元素.这样是解决问题了。不过其提供的validation框架由于对DispatchAction的实现方式不支持，降低了<action path=""/>对多个处理请求的重用性，如：" 添加"、"修改"则有可能大多数数据相同，但因为个别信息处理有所不同而需要重新再配置一个对应的<form-bean>和<action path=""/>,这无疑也增加了一些，项目的复杂度，因为从配置上看，又多了一些需要关注的对象，虽然这些对象的实现类都是同一个。希望在Struts的后续版本中，能将这些互相不配合的实现消灭，更加完美.