程式設計珠璣 對DAO層的一點修改

由於以前的domain物件都是不需要序列化的，所以為了運算元據庫查詢的方便，直接採用繼承basedomain的方式來完成。這樣在傳遞動態引數的時候，只需要把引數放到map總，就可以很好的在ibatis配置檔案(map.xx來直接獲取值)中使用。

這樣導致的乙個害處就是物件看起來有直接根本就不需要的屬性，即使你新增關鍵字transient，不少程式設計師依然在set的時候會費解一些不必要的屬 性。例如：在insert()設定屬性的時候竟然能夠setpageno()。質疑這個很有道理，但是以前一直extends粗暴簡單的來完成任務，沒有 額外的系統設計問題，所以就得過且過，沒有繼續抽象。

目前，domain物件需要額外提供序列化的功能和為api服務，簡單粗暴的方式不能繼續適應系統要求，所以需要繼續抽象。在crud的模型中，逐個分析需求變化導致的問題。

insert() , update() , delete() 都可以直接傳入物件，不需要額外的值，即使有這樣的條件，也建議不動態傳值到ibatis中；

find() , list() 需要動態出入引數，同事find和list傳入的引數值有所不同；list和find引數存在繼承關係；

按照需求，設計抽象有3點：

uml關係圖如下：

程式設計珠璣 對DAO層的一點修改

由於以前的domain物件都是不需要序列化的，所以為了運算元據庫查詢的方便，直接採用繼承basedomain的方式來完成。這樣在傳遞動態引數的時候，只需要把引數放到map總，就可以很好的在ibatis配置檔案 map.xx來直接獲取值 中使用。這樣導致的乙個害處就是物件看起來有直接根本就不需要的屬性...

我對持久層的一點看法

最近做專案，有乙個星期的時間，都在跟同事討論 持久層怎麼辦？是自己搞，還是用個持久層框架？最後決定還是自己搞吧。因為資料庫結構一直都在變，用了持久層的確不方便。雖然，從某種程度上來講，持久層的確能減少 量。更重要的是，資料庫已關係 表 為處理單元，而程式是以物件為單元。因此，這種物件與關係的對映是很...

超菜鳥對三層的一點理解

因為新的專案要用到三層架構,所以在專案還沒有開始之前,專案經理一直叫我多看些這方面的知識.這不,今天他叫我寫一下自己對三層的理解,這個可叫難啊.乙個自己的整體水平還沒有達到這個境界,另乙個也就才看這方面的知識一段時間.感覺自己的心情與因為擔心自己畫的地圖會改變世界而不敢畫地圖的朋友一樣,不知自己對這...