了解了hibernate之後，發現hibernate把大部分日常操作都歸結為幾個類.
configuration
sessionfactory
session
query
criteria
這幾個類的相互配合就能做好持久化的工作，基礎編碼人員頁不需要了解其他的類和介面，就能很好的完成工作。這不禁讓我想起我們類庫中有很多任務具類，業務核心類但是沒有人去了解，原因是類太多了。所以在編碼中經常不規範，本來基類中實現的**到處都有重新的實現，核心的業務功能不斷的被重新實現；很難管理，究其原因，是因為類太多了，設計的範圍太廣了。這不禁讓我懷念起以前的上帝類來，當時雖然設計不優雅，但大家都知道在需要的時候呼叫上帝類。
思考現在的模式，感覺目前的類庫和業務核心封裝應該也組織出幾個數量有限的「上帝類」出來，不過此「上帝類」非彼上帝類，該「上帝類」不做功能的實現，只做proxy或者wrap，將核心類的數量控制到最小，保證大家能盡可能的使用，真正提高**的復用率。也許是乙個好主意。
Buff系統框架設計
buff的配置檔案 buftype 1 精神類buf 2 物理類buf 3.元素類buf 4.其他類buf 5.被動類buf bufsubtype 1000 1999 精神子類 2000 2999.物理子類 3000 3999.元素子類 4000 4999.其他子類 5000 5999.被動子類。所...
再議成就系統框架設計
根據的設計，其實還有幾點可以優化 1.group組的buff是靠嚴格的配置的偏移量計算出來的，這個太不可控了。buff可能出在無法檢查的策劃小錯誤上 2.如果已經有n種型別的成就，而有乙個新的需求，其事件是已有的幾種成就組事件的組合，則需要 產生一種新的成就組，使用新的成就buff。儲存空間浪費，冗...
系統介面框架設計與實現
目錄 1 引言 2 設計 2.1 inte ce 2.2 business service 2.3 object transaction data 3 實現 3.1 webservice.asmx 3.2 ibusinessservice 3.3 common submitresult 4 使用說明...