很早以前做了以下兩件事：
1、對.net下的資料庫訪問技術做了乙個簡單的封裝，對於任何的資料表，都可以採用統計的結構進行訪問。
2、然後做了乙個**生成器，對不同的資料表進行一些類的封裝。
這樣的計畫幾乎是完美的!而且在我後來的所有與資料庫打交道的專案裡，都採用了這種架構模式，而且效果還不錯。
沒想到卻有這樣的乙個小錯誤：
1、表中的每一條記錄是用hashtable進行快取的，在不明確資料庫裡有哪些欄位時，是直接先在快取的hashtable裡的。然而，沒想到，它按key讀寫資料時是大小寫敏感的。這本來也沒什麼，因為**生成器會根據資料庫裡的欄位名的大小寫自動匹配。但是，前幾個星期，因為對資料庫做了乙個小的修改，原本要用**生成器對類**進行一次修正。但我認為修改的內容不多，所以就自己手動的修改。結果，這個大小寫讓我犯了兩次錯誤。
2、更鬱悶的是，類與資料庫中的字段出現了錯位。因為自己以為手動修改**是成功的，沒想到n天前的錯誤隱藏到今天。而且還是經過多次除錯才發現，原來字段沒有對齊。
這是很鬱悶的錯誤，原來不應該發生的。如果當是不是太自以為是，還是用工具把**修正一下，就不會一錯再錯了。再就是，不能對架構裡的內容太信任，因為一直相信底層的資料庫訪問是經過了考驗的，不是會有問題的，所以一直沒有把錯誤的目標定位好，使查詢錯誤花了很長時間。
這使我對框架的設計有了更進一步的認識。以後在設計這樣的框架的時候要多加小心了，不能希望你的使用者在你設計的框架裡是友好公民，你要充分的認識到，他有可能會做一些你想不到的事情，讓你的框架出現低階的錯誤。這是很不應該的。再就是，針對再完善的框架，它都有不足的地方或者出現錯誤的時候，因此在出現錯誤時，不能因為框架曾經穩定過就忽略對它的錯誤檢查。
框架設計的粒度
先拿乙個常見的oa中的許可權管理舉例，常規的設計方式無非就是許可權 角色 人這三層，關係如下 那麼這樣的許可權設計是可以基本滿足乙個oa的需要的，那麼只需要做乙個filter去進行許可權的控制就ok了。如果考慮到軟體的擴充套件性貌似也足夠用了。但是考慮一下顯示情況，如果上線之後許可權需要增加意味著什...
現用框架設計的基本設計
基本設計 框架是為了解決 出現大量的冗餘，和提高開發人員的開發效率，而這些框架的基本設計，都是將一些變化的資料的值存放到乙個檔案中，而這個檔案必須要是乙個關係對映檔案，而已是可以符合複雜的硬關係和軟關係對映的，因為在專案中可能會出現大量問題，而要應對這些問題則需要提供相應的路徑來解決。而這個檔案的最...
反射 框架設計的靈魂
獲取class物件的方式 1.class.forname 全類名 將位元組碼檔案載入進記憶體，返回class物件 多用於配置檔案，將類名定義在配置檔案中。讀取檔案，載入類 2.類名.class 通過類名的屬性class獲取 多用於引數的傳遞 3.物件.getclass getclass 方法在obj...