|
|
Posted on 2006-07-23 21:02 大大毛 阅读(327) 评论(0) 编辑 收藏 所属分类: Struts
快有一个星期没有更新学习进度了,不过这几天我也没闲着,还在啃书中....
学习的要点在于实践,这一章的书已经看完,不过实践过程中涉及到的技术实在是很多,很多时间都花在了网络资料的查找以及本书后面几章中相关技术的学习上.
这一章中挖掘出来的东东:
1.解析XML的Digester;
2.数据源的配置(DBCP);
2.1连接在运用上的结构问题;
3.页面控制流程的跳转;
4.标签类的内部设计;
下面详细解释一下:
解析XML的Digester:
这里我
有一篇
有关类使用的介绍
DBCP数据源的配置:
介绍在
这里
连接在运用上的结构问题:
这个问题是针对例程提出来的.例程中实际用到连接的在AddressBookBean中,而有关数据源的getConnection()方法被放于DbUtil工具类中;在结构上DbUtil.connectionToDb()和AddressBookBean的insert(),search()方法被设计为static,这样的设计在用自定义数据库连接时没有什么问题,但是我现在的要求是使用Struts数据源,问题就出来了,DbUtil只是一个普通的用户类,在里面我无法拿到DataSource(暂时我还没有找到解决方法),因此我需要在结构上做一些改动:
想法:
1.在DbUtil上增加一个static void setConnection()接口,这样做的好处是改动不大;
2.在JavaBean上改动数据操作接口,让它依赖于外部Connection传入,这样做的好处是看起来比较OK一些,降低一点逻辑层与数据层的藕合.
基于以上两种方法的考虑,我在实践中采用了第2种方法,同时也在后续的自定义标签设计中为此付出了代价
页面控制流程的跳转:
起因:我又改动了设计结构,原本由menu.jsp实现link,我把它改成menu.jsp --> menuAction -->forward,这样改的好处是在struts-config.xml设计视图中就可以很清楚地看到整个应用的流程,嘻嘻.
方法:menu.jsp上加入一个form以及一个hidden,在<a>中调用JS实现action的提交,menuAction中来个findAction(action);
小插曲:对于应用中的那个displayAll模块,我先前是让它的forward指向searchAction.do,在跳转之前,压个SQL进session,不过我得到的却是可耻的失败,action之间的跳转没有达到目的(menuAction -> searchAction -> display.jsp),跳转的结果成了这样(menuAction --> search.jsp),我在forward中设置的search.do根本就没有得到控制权,而是直接跳到它的input页面去了,多方查资料,至今尚未得到解决(已经解决,参看这里.).
只能再改动成(menuAction --> display.jsp),由标签实现display功能,而session中sql对象的压入也被迫放在了两个地方(menuAction,searchAction),这个有点不爽,看起来还是例程中的(menu.jsp -> search.jsp + menu.jsp -> displayAllAction)设计要好一些.
标签类的内部设计:
ValidateSessionTag标签的设计没有什么可改变的;
DisplayTag标签需要做相应的改动:
1.由于之前我在JavaBean使用Connection的结构上做了变动,因此这里也要产生变化了,在DisplayTag中我需要拿到那个DataSource,
Connection con = ((DataSource)this.pageContext.getServletContext().getAttribute(Globals.DATA_SOURCE_KEY)).getConnection();
当然了,标签上应该增加属性,允许设置DataSource的key
2.既然Struts需要实现国际化,标签也应该对应着进行一点改动,DisplayTag中要显示一整个<table>元素,而例程中的表头的生成显然会产生问题,表头元素应该是从资源文件中取.
((MessageResources)request.getAttribute(Globals.MESSAGES_KEY)).getMessage(request.getLocale(), key );
如果考虑周全点,同上一点一样,也应该增加属性才行
思考:
经我改动的数据操作上还是存在麻烦,由于在标签类内部引用了DataSource,这样就遗留下隐患,从类的结构上可以看到自定义连接的DirverManger与DataSource根本就是两条线,这样如果我的应用不用这种连接池的设计,而是改用自定义连接的话,很显然这个标签是需要进行改动的,这显然不爽于仅仅改动一个工具类.因此我的考虑是,在实现上应该从更加通用的Connection接口着手.
具体实现:
自定义接口DbSource,在此接口中仅有一个方法public Connection getConnection();让自己的数据库工具类实现这个接口,这样在众多的应用中,就可以把传入的对象向DbSource接口转化,从而成功的得到Connection对象.这样做的好处就是让这个DbSource接口充当适配器的角色,从而将Connection与具体的连接方式隔离开来.
如果应用在例程上,也可以解决从各个地方直接调用一个类的不好现象(接口毕竟比类通用啊)
|