SSH框架使用概述.doc

SSH框架使用概述前言使用新框架主要是处于系统代码的可扩展性和可移植性两方面进行考虑。在早期的代码编写中，没有特别规范代码的层次结构和编码形式，因此程序员往往不考虑代码层次结构的设计，只关心功能的实现和执行效率。随着时代的发展，计算机硬件水平的不断提高，代码执行的效率由计算机本身的运行速度所决定。程序员不必过分的追求代码的执行速度。因此代码风格和层次结构成为开发人员更为关心的内容。与此同时，客户也随着时代的改变需求也随之更新。要求系统不断的进行升级和改造，这样，开发人员要不断的对系统的各个部分进行改进。往往因为一个很小的问题，导致人们要从底层一直改进的页面展示。从而出现“牵一发动全身”的现象。显然在使用老的层次结构来面对如今快速更新发展的需求是不合适的。因此，使得程序员们对代码的层次结构和改进成为一件刻不容缓的事情。基于上述考虑，项目组在北京市目录三期系统中，对框架进行了改进，采用了SSH的结构。下面我通过在使用新框架开发项目过程中的一些感受进一步进行讲解。分析说到SSH技术，因此就一定先要谈一谈mvc开发模式。大家请看这张图，这张图就是mvc最简单明了的一张关系图。任何技术和框架都有优缺点，我们只有了解了他的优缺点才能将它更好的应用在我们的系统中。我将结合北京市三期目录系统具体说明mvc结构的优缺点。MVC的优点低耦合性。视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。高重用性和可适用性。随着技术的不断进步，现在需要用越来越多的方式来访问应用程序。MVC模式允许你使用各种不同样式的视图来访问同一个服务器端的代码。它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。例如，很多数据可能用HTML来表示，但是也有可能用WAP来表示，而这些表示所需要的仅令是改变视图层的实现方式，而控制层和模型层无需做任何改变。较低的生命周期成本。MVC使降低开发和维护用户接品的技术含量成为可能。快速的部署。使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中业务于表现形式上。可维护性。分开视图层和业务逻辑层也使得WEB应用更易于维护和修改。有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。MVC的缺点MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序到来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。根据开发者经验，由于开发者将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。MVC是一条创建软件的好途径 MVC设计模式是一个很好创建软件的途径，它所提倡的一些原则，像内容和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的构件，你可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。组件与框架的结合日志组件日志组件module层树型展示组件列表展示组件视图层（view）控制层（Controll）持久层（Module）使用新框架遇到的问题及解决方案1.延迟加载问题在使用hibernate中，由于需要有表关联，但是出于对系统性能的考虑，需要用到延迟加载，在使用中会发现，spring封装的hibernate和纯hibernate的使用是不同的。因为纯hibernate可以自己利用session工厂控制session的打开和关闭。而spring封装的hibernate测试由spring来控制事务的管理。所以可能出现在dao层延迟加载能够使用，但是在service层就出现session关闭的情况。所以，我们现在解决的方式是在web.xml中对hibernate加上过滤器，如： hibernateFilterorg.springframework.orm.hibernate3.support.OpenSessionInViewFilter sessionFactoryBeanName mySessionFactory 对那些service进行事务管理，这样统一管理事务解决了延迟加载的问题。2.主键生成问题在使用hibernate中，往往产生主键的方式是由hibernate提供的，但是hibernate产生主键对数据库要求特别依赖，所以需要通过自己写如产生主键的方式，所以将配置文件改成assigned，但是后来发现，如果当程序员在编码的时候需要到处调用产生主键的方法，而且一旦程序员忘记写，程序就会出错，所以我们借用了hibernate统一管理主键的思想，在配置文件中加载产生主键的类，对主键统一管理。 meta 6 3.Structs标签使用不熟练 在页面的开发中我们使用struts技术，遇到了标签的困难，使用不是很熟练，而且文档较少，用起来有时候也不是特别方便，所以后来用jstl标签和EL表达式来解决struts标签中麻烦，不易操作的困难。4. 配置文件调用方式在使用spring中，需要调用service的资源，这样需要资源注入，其中有三个注入的方式，最后根据简单和使用性的比对，采用了让struts交给spring管理注入资源的方式。这样可以将所有的注入资源放在一个配置文件中，不用每次调用都要加载文件，提高了运行效率，同时解决了延迟加载的问题。5. Bean的引用方式再spring的配置文件中bean的相互引用有两种方法：，第一个方法为不同配置文件引用，第二个方法为同配置文件中的引用。一般会只想到使用第二个方法，可是当项目里用到多个spring配置文件时，配置文件之间的相互引用就必须使用第二中方法的注入，否则得不到注入的bean。所以多配置文件里的属性要熟悉。6. Action类的编写问题在页面进行请求时需要调用相应的action响应事件action，action的写法有两种，可以是为每个请求建立一个单独的action，也可以为不同的请求建立同一个action，比如：在同一个表进行增加、修改、删除以及查询操作时不必要为每个事件都建立一个action，而是这几个请求同一个action，然后在struct的配置文件中指定不同的action中方法名来处理，如：相对与前一个方法，第二种方法配置更简单，而且减少了action类的数量。7. Action请求路径冲突问题在struts的使用过程中，应该在action的请求路径中加上自己模块的名称，来区分不同模块的请求；比如两个模块都需要调用一个公共的接口，在配置文件里集中处理action的请求时把所有模块的请求路径写在一块，有可能存在相同的请求，如果有相同的请求路径时会发生冲突错误，这样的情况有很大机率发生。所以我们需要在action的请求的名称前加上模块的名称，来避免冲突问题。8. 分页查询问题在使用Hibernate和Spring时，它提供了getH