玻璃杯中的花生壳--项目小结（hibernate + spring + webwork)

[java]项目小结（hibernate + spring + webwork)

[ 2006/8/8 17:18:42 | By: 玻璃杯中的花生壳 ]

　项目小结（hibernate + spring + webwork) 目前情况：自动工单管理系统，使用自开发的类似struts的架构，数据库访问经过包装，返回string数组。其架构问题： Action使用同步锁，导致在同一时间只能进行一次web访问，如同时有其他访问，将不必要的被阻塞。结构不够清晰，不能够完全按mvc的思想明确的分离各层逻辑。jsp代码过多且结构零乱，没有把通用的代码用taglib等技术抽象，后续开发困难业务逻辑和数据库紧密相关，而没有从表实现中抽象出来。同时，在每次使用同样的业务逻辑的时候都要反复的进行相关sql编程。故而与数据库有强耦合，相关程序重用性低，可读性差。其翻页机制逻辑横贯架构，使层次高度耦合，而数据库封装也可能存在性能问题。同时，客户也提出了不少整改意见，而在原版本的修改和升级都会较为困难，而且对长期的维护不利。项目分析：目前的各种业务管理系统还是将以j2ee的b/s架构为主流，所以有必要完成一个通用的，稳固的整体架构作为以后各种应用的坚实基础。我认为应尽可能使用业内先进的免费框架技术而不是自开发框架。好处是：这些框架技术凝聚很多业内精英的智慧，而且经过发布和使用，技术体系已经成熟，性能有所保障。层次清晰，符合先进的技术理念和设计模式。同时也容易找到熟悉相关技术的人才，维护和后续开发方便。相比之下自开发框架因为技术实力和时间问题，很难达到这些业内领先框架的技术高度。分析一般的j2ee应用，应有如下层次：显示层负责界面显示，接受用户指令显示层有较为经典的MVC，即model,view,control，进一步了细化了显示层的工作。此类著名框架有struts，webwork,spring-mvc等。经考察，我认为struts虽然是时间最长最成熟的技术，但易用性和一些架构理念不如webwork，而view层的开发应尽可能简单快速。故选定用webwork. 逻辑层负责进行业务逻辑的实现目前的开发过程，往往陷入逻辑层和数据访问层不能分离的情况。面向对象的项目开发最后演变成成程序员在程序各处手工写sql操表。这样做的优点是开发迅速有效，问题是结构将日益混乱，每次逻辑的变化将不得不修改分散于各处的sql语句，而后续的程序员也必须了解整个程序和数据库结构才能进行修改。如果是短期小型项目，可以用这种方式。否则的话，我认为应尽可能贯彻面向对象思想，把业务逻辑抽象出来。而逻辑层的工作就是针对实体对象进行业务逻辑的实现。我们针对所有的业务操作，对外提供service接口，既服务接口。这类似tuxedo和ejb所采用的业务外观模式。而为填补service生存周期管理的空白，我们使用著名的spring框架。优点：实现Ioc，使各层次的耦合可配置化。按需要实现单例模式等，进行生存周期管理事务管理。Spring的宣言事务管理（Declarative transaction management）使得一般场景的代码中将不需要考虑事务问题而集中于业务逻辑拦截机制将为程序提供很好的扩展空间 3. 数据访问层负责将类操作映射为数据库操作。进行实体类的持久化。从而将所有的数据访问工作集中起来这一层我们将完成实体类持久化(persistence)，有若干选择： 1 jdbc实现 2 使用ORM工具如hibernate,ibatis,jdo 经过实写代码，感觉用jdbc实现dao效率非常低，而且容易出错。经过考量选用hibernate。和ibatis相比虽然上手慢且不够灵活，但其架构思想和强大功能都受到业内一致好评，甚至是ejb3也深受hibernate影响。所以hibernate是很好的选择。项目设计综上，我们使用 webwork+spring+hibernate的架构。版本：webwork-2.1.7 spring1.2 hibernate-3.0.3 经过一段时间的开发，目前架构基本成形： 500)this.width=500'> 在src目录下为java源码 dao 负责数据访问对象的定义和实现其中Dao结尾为接口，Impl结尾为实现。目前一般用hibernate做实现。domain 实体对象logic 针对实体对象封装的逻辑这里service是外观接口，serviceimpl是实现，考虑目前情况简单，并没有进一步分离逻辑，业务逻辑都在impl中完成。 web 界面相关的java类 common是一些常用类，如处理中文问题的filter. displaytag中放了displaytag相关的类，多为wrapper. webwork中都是对应的action，其中 BaseAction是基本的抽象类，基本后续开发应继承此类 CrudAction是为了一般的Crud工作而作的一个抽象类，可以继承用来简化工作。而CaseDispatcher负责菜单点击后分发到相关Action，同时处理权限和session工作。其他action按模块进行了组织 500)this.width=500'> 左边是webroot的结构重要的配置文件有： Spring applicationContext.xml applicationContext-db.xml Webwork xwork.xml webwork.properties i18n labels.properties log4j log4j.properties displaytag displaytag.properties dbConnect jdbc.properties 关于一些技术难点和细节： 1．各框架连接：spring到hibernate使用spring的hibernate支持。Spring到webwork使用autoware的拦截机制自动装配。 2．列表的问题，采用displaytag。功能强大，使用简洁，可实现排序和数据导出。 3．数据下载，使用displaytag自带的excel下载 4．文件上传，使用webwork提供的解决方案，用拦截机制实现。 5．jsp代码组织方面，我们使用taglib和css技术使jsp中页面逻辑减少到最小，一般情况完全可以不使用<% %>的script段。同时我们使用两个include来包含常用的taglib定义，js引用和html结构，使jsp代码非常简洁。 6．中文问题我们使用filter来解决页面gbk到java程序unicode的转换，同时通过正确的设置数据库连接url完成和数据库之间的交互。 7． I18n国际化。我们要求在jsp代码中不出现中文，所有提示信息都通过资源文件labels.properties来完成。页面中可以使用jstl或webwork标签来调用。 8．界面验证问题。使用webwork的validate机制用xml定义，或在action中代码判断。

阅读全文(3007) | 回复(1) | 编辑 | 精华

回复:项目小结（hibernate + spring + webwork)

[ 2006/8/20 12:58:21 | By: nuthell(游客) ]

兄弟，我顶你！真是辛苦你了。-----------nuthell@gmail.com

个人主页 | 引用回复 | 主人回复 | 返回 | 编辑 | 删除

» 1 »

发表评论：

昵称：
密码：
主页：
标题：

验证码： (不区分大小写,请仔细填写,输错需重写评论内容！)