Jive筆記--Database Package下面的暗黑世界

2019-11-18 13:26:36

字體：大中小

供稿：網(wǎng)友

　　Jive再牛B,歸根到底還是要和Database打交道的。
　　還不一樣要調(diào)用getConnection(),CreateStatement(),ResultSet.next()。
　　那么，我的疑問是，Jive是怎樣處理低層操作類(DBForumMessage/DBForumThread/DBForum)之間的耦合關(guān)系的呢？
　　由于存在了Cache,所以，DBForumFactory/DBCacheManager/DBForumXXX這些類之間的關(guān)系可謂是錯(cuò)綜復(fù)雜。
　　
　　(1)真正實(shí)作中，我們?cè)鯓觼硗瓿杉虞d一個(gè)ForumMessageObject? 還有thread的增加刪除Message是怎樣完成的？
　　打開DBForumMessage.java，發(fā)現(xiàn)，除了完成ForumMessage Interface的方法以外，還有幾個(gè)PRivate的方法和Protected的方法。
　　分別是：
　　private void loadFromDb();
　　private void saveToDb();
　　protected void insertIntoDb();等
　　
　　上面三個(gè)函數(shù)分別用來完成對(duì)jiveMessage表的SELECT/UPDATE/INSERT操作。
　　所以初步可以判定，對(duì)jiveMessage表的操作，基本上封裝在了DbForumMessage里邊了。但不是全部，為什么？慢慢往下看。
　　
　　a.加載DbForumMessage
　　非常簡單，地球人都知道的代碼。在一個(gè)構(gòu)造函數(shù)中調(diào)用loadFromDb()，然后執(zhí)行SELECT xxx,xxx,..WHERE id=...，假如rs為空則拋出
　　MessageNotFoundException，否則，一個(gè)一個(gè)的把字段內(nèi)容復(fù)制給DBForumMessage的成員變量。
　　(順便這里提一下，這些映射數(shù)據(jù)庫字段的成員變量有些是Private的，有些是Protected，為什么呢？呵呵。)
　　對(duì)于這樣的加載方法，假如沒有Cache，將會(huì)非常慢的。試想，每次顯示一個(gè)Message都要一次Select,我瀏覽Thread頁面的時(shí)候，一次顯示n個(gè)Thread/Message,....
　　還不要數(shù)據(jù)庫的小命啊。
　　
　　在我克隆Jive的過程中，由于Cache機(jī)制將在以后實(shí)現(xiàn)，所以采取了一個(gè)折衷的辦法。改寫了DBMessageIterator()類，改原來的只取ID
　　為取回除了Body以外的所有的內(nèi)容，并且直接就地New DBForumMessage，然后復(fù)制到ArrayList。
　　至于Body，則采用LazyLoad的方法，等用到了才去SELECT body FROM ...
　　這樣處理，由于有ResultFilter的限制，最多復(fù)制幾十個(gè)沒有Body的DBForumMessag 對(duì)象，這對(duì)于AppServer來說，我想影響不大吧？
　　
　　b.增加DBForumMessage
　　也就是調(diào)用INSERT INTO jiveMessage啦。不過，注重到，在插入新的ForumMessage紀(jì)錄的時(shí)候，ThreadID是必須的，
　　所以看起來只能讓DBForumThread來調(diào)用這個(gè)方法了。難怪!!用了protected insertIntoDb(DbForumThread)!! 原來，同在一個(gè)包下的class是
　　可以互相訪問protected的方法的。偶java基本功不行，呵呵，到了今天才發(fā)現(xiàn)的這種現(xiàn)象。
　　
　　c.刪除DBForumMessage
　　這個(gè)比較有趣，DBForumMessage沒有任何執(zhí)行DELETE FROM jiveMessage的代碼，看起來一定是在外邊DBThread實(shí)現(xiàn)了。
　　究竟，這個(gè)是thread的事情嘛。果不出所料，DbForumThread::deleteMessage()里邊直接執(zhí)行了DELETE SQL.
　　我自己在Clone Jive的時(shí)候，還是作了小改動(dòng)，給DbForumMessage添加了protected deleteFromDb()方法，把執(zhí)行SQL的操作放給Message完成了。
　　
　　在對(duì)Message進(jìn)行Add/Delete操作過程中，可不能忘記了Cache List的更新，所以必須記得在DbForumMessage中調(diào)用cacheManager的一些方法
　　來更新Cache，雖然目前在我的系統(tǒng)中，這些函數(shù)是空的 :)。
　　
　　明白了Thread/Message之間的"父子關(guān)系"，F(xiàn)orum/Thread Category/Forum之間的關(guān)系也就差不多啦。哦，Jive中的Category似乎有點(diǎn)非凡，
　　等偶下次看了代碼再另外具體匯報(bào)。
　　
　　(2)DBForumFactory是個(gè)什么東西？
　　Jive2.1.1以后，DbForumFactory不給Source了，而且，JAD還很難反編譯，因?yàn)槲野l(fā)現(xiàn)JAD無法反編譯諸如synchronized(Object){}這樣的代碼。
　　還好我們有Jive 2.1.1的代碼。哈哈。看看再說。
　　先把DBForumFactory的身份給揭穿。其實(shí)DbForumFactory是個(gè)總管。總管Forum/Thread/Message。
　　所以，我們?cè)谡{(diào)用API的時(shí)候，都是通過Factory.getForum()/getThread()/getMessage()來獲得那些對(duì)象。
　　Jive用了SingleTon保證DbForumFactory()唯一，即靜態(tài)方法DbForumFactory.getInstance()。
　　同時(shí)，DBForumFactory在構(gòu)造函數(shù)中New了一個(gè)DatabaseCacheManager。因此Factory和CacheManager就這樣勾結(jié)起來了。
　　所有調(diào)用getForum(),getThread(),getMessage()，都是調(diào)用DatabaseCacheManager的相關(guān)方法來實(shí)現(xiàn)的。
　　例:
　　
　　DBForumFactory::getThread() ==> DatabaseCacheManager.getThread() ==> Search Cache or new DbThread object
　　
　　結(jié)論，DbForumFactory不是東西。除了檢測Licese是否合法，其它基本上就是一個(gè)二道販子。
　　
　　(3)其實(shí)還有那些Thread/Message的DbIterator，在Jive筆記4中已經(jīng)提到了。不必再羅嗦一遍。
　　
　　寫了這么多，感覺還有好多東西沒有講。我希望大家能夠仔細(xì)體味里邊的protected 屬性/方法，我認(rèn)為，這些東西其實(shí)和友元差不多，
　　它們部分的打破了封裝，但是獲得了很大的靈活性。
　　退后一步想想，我們只要把那些東西一股腦兒的限制在database package里邊，對(duì)于整體上的封裝，還是沒有什么影響的。
　　
　　呵呵，一家之言，請(qǐng)大家不吝指教

上一篇：談?wù)凧AVA的反編譯

下一篇：JCA: Java步入應(yīng)用集成時(shí)代