在企業級應用當中，資料是企業資源的重要組成部分。應用程式的開發也是圍繞資料的組織和儲存、資料的訪問、資料的處理、資料的表示進行的。由於這幾個方面為整個應用程式系統提供了服務(service)，因此我們可以把這幾個方面統稱為資料服務(不知道用這樣的名詞去概括是否恰當)。 我們從企業應用程式常用的三層或者多層結構可以看出，每一層都無法離開資料，每一層都擁有乙個獨有的關注點。正是由於資料在企業級應用程式中舉足輕重的作 用，各種各樣專注於資料服務的技術和工具層出不窮，像.net世界中的data access control，像j2ee世界中的ejb等等。
縱觀資料服務的各個層面，資料的組織和儲存自然是資料庫的天職了；而資料的處理則是跟專門的業務邏輯緊密聯絡的，開發可重用的元件有非常大的難度，而且復用的範圍會受制於行業之間的巨大差異性。那麼，復用的範圍就縮小到了資料的訪問以及資料的表示
我們先來看乙個較為完整的團隊的組成結構：project manager，system architect，system analyst，database administrator，database designer, tester，advanced programmer，programmer。對於以上的團隊組成，我想對於有專案經驗的朋友來說，一定不會陌生
了，但是你或許會覺得有點迷惑，講述資料訪問模式方面的思考，為什麼要先從團隊結構入手呢？或許你還記得ejb核心技術所涉及的六種角色吧，畢竟
技術的選擇以及使用的情況都會直接影響到團隊的組成。還記得在上個專案當中，我只是乙個小小的程式設計師，由於公司在o/r maping方面使用了
entity bean並且在應用程式框架中實現了乙個相當簡陋的data accessor(說它簡陋，是因為data accessor僅僅是對jdbc進行了很簡單
的封裝，除了connection不用再花心思之外，sql照寫不誤)，那麼涉及到資料庫的查詢操作就用data accessor，其他需要修改資料表的操作則一律使
用entity bean提供的方法，甚至一些複雜事務的處理亦是如此。在這樣背景下，團隊中僅由兩個人身兼database administrator和database
designer兩職。然而事實上，他們手頭上的工作僅限於administration的工作——建立並維護用於開發的資料表，雖然人少，也能勝任。隨著專案
開發的深入，過度使用entity bean，過度依賴應用伺服器而造成的效能問題逐漸顯露。於是system architect向project manager提出需要充
分利用資料庫伺服器的能力。那麼，如何去調整應用伺服器和資料庫伺服器的負載比例呢？策略就是將複雜的事務處理裝到儲存過程中。好了，這下
子dba開始忙活了，兩個人天天加班都沒有辦法跟上進度，於是除了我這個小小的程式設計師之外，還有很多同事也可以開始寫儲存過程了，一時間，團
隊中的database designer增加了許多許多，無法工作、難以維護的儲存過程也相應出現了許多，畢竟我們並不是真正的database designer。
講述這個故事，無非是想強調資料訪問模式本身的重要性。忽視了資料訪問，對其各個方面考慮不夠，將會對專案的開發造
成極大的影響。
廣和深的內容：物件的標識，實現聚合關係，實現繼承關係等。有了這樣完整的對映關係，我們就不再需要面對艱深晦澀的sql，而是通過操作物件
關於資料訪問模式（五） Layers模式
layers 層 模式，我想大家應該都不會陌生了。不管是硬體驅動程式 tcp ip協議，還是j2ee應用軟體的架構，層 的強大之處在 呢？我們是否真的了解層的劃分呢？我們面對乙個複雜問題的時候，都會想著將這個問題化整為零，分為乙個個子問題，然後逐個擊破。相應 的，處理這樣複雜問題的軟體也會進行劃分。...
資料訪問物件模式
資料訪問物件模式 data access object pattern 或 dao 模式用於把低階的資料訪問 api 或操作從高階的業務服務中分離出來。以下是資料訪問物件模式的參與者。我們將建立乙個作為模型物件或數值物件的 student 物件。studentdao 是資料訪問物件介面。studen...
設計模式 資料訪問物件模式
上文 設計模式 組合實體模式 經歷過jsp頁面請求jdbc然將資料庫中的資料直接查出後直接返回給控制器，然後jsp渲染的痛，相信經歷過的都很清楚，這樣的很難維護，而現在流行的mvc模式，其實m分為dao和entity兩層，dao負責與資料庫互動，而entity作為資料模型，很好起到了隔離作用。資料訪...