|
|
Posted on 2006-07-23 21:02 大大毛 閱讀(340) 評論(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與具體的連接方式隔離開來.
??????如果應用在例程上,也可以解決從各個地方直接調用一個類的不好現象(接口畢竟比類通用啊)
|