幾乎全部結構良好的軟件都使用了分層設計。分層設計將一個應用程序根據技術職能分爲幾 個內聚的部分,從而將某種特定技術或接口的實現細節與其餘部分分離開來。分層設計能夠用任 何一種強壯的編程語言來實現。圖1-2給出了一個典型的的高級視圖,該 圖對於許多商業應用程序都是有用的。html
下圖中的箭頭讀做「依賴於」或「使用」。這種分層設計其實來源於迪米特法則,該法則的一種表述方式就是,「每一層都應該只對那些與本身緊密相關的層有有限的瞭解。」數據庫
每一層都只與本身的直接下層「交互」。這就保證了依賴流(dependency flow)只有一個方向,從而避免了那種在沒有分層設計的應用程序中很是廣泛的披薩式的代碼。編程
MyBatis是一個持久層框架。持久層位於應用程序的業務邏輯層和數據庫之間。這種分離很是重要,它保證了持久化策略不會混入業務邏輯代碼,反之亦然。這種分離的好處就在於你的代碼將更加容易維護,由於它容許對象模型的演化不依賴於數據庫設計。架構
雖然MyBatis關注的主要是持久層,但理解應用程序的總體架構中的每一個層仍然是很重要的。 雖然經過分層設計能夠將關注點分離,從而將對任何一種特定實現的依賴都降到最低(甚至沒有),但若是你認爲這樣就能夠無論其餘層的存在,不顧與其餘層的交互,那就太天真了。不論應用程序設計得多麼完美,你都必須明白層與層之間必定存在某些間接的行爲關聯。如下各節將 討論應用程序的各個層以及MyBatis與這些層的關係。框架
業務對象模型dom
業務對象是一個應用程序的全部其餘部分的基礎。它是問題域在面向對象方法學中的一種表現,所以構成業務對象模型的各個類有時也被稱爲領域類(domain class)。全部其餘層都使用業務對象模型來表現數據和執行某些特定的業務邏輯功能。數據庫設計
應用程序的設計者們一般都是從業務對象模型的設計開始的。即便從較高的層次上看,業務對象模型中定義的各個類也都來源於咱們的問題域中的名詞。隨着應用程序愈來愈複雜,類表明更抽象的概念。編程語言
業務對象模型類中固然也可能包括一些邏輯,但它們決不能包含任何用於訪問其餘層(特別是表現層和持久層)的代碼。此外,這個業務對象模型絕對不能依賴於其餘任何一層。其餘層可 以使用業務對象模型——但永遠不能反過來。spa
像MyBatis這樣的持久層一般會使用業務邏輯對象來表現存儲在數據庫中的數據。業務對象模 型中的這些領域類將成爲持久化方法(persistence method)的參數和返回值。也正是由於這個緣由,這些類有時也被稱爲數據傳輸類(data transfer object, DTO)。雖然數據傳輸並非它們惟 一的做用,但從持久化框架的角度看,這個名字仍是至關合適的。設計
系列文章: