標籤:
幾乎所有結構良好的軟體都使用了分層設計。分層設計將一個應用程式根據技術職能分為幾 個內聚的部分,從而將某種特定技術或介面的實現細節與其他部分分離開來。分層設計可以用任 何一種強壯的程式設計語言來實現。圖1-2給出了一個典型的的進階視圖,該 圖對於許多商務應用程式都是有用的。
中的箭頭讀作“依賴於”或“使用”。這種分層設計其實來源於迪米特法則,該法則的一種表述方式就是,“每一層都應該只對那些與自己緊密相關的層有有限的瞭解。”
每一層都只與自己的直接下層“互動”。這就保證了依賴流(dependency flow)只有一個方向,從而避免了那種在沒有分層設計的應用程式中非常普遍的披薩式的代碼。
MyBatis是一個持久層架構。持久層位於應用程式的商務邏輯層和資料庫之間。這種分離非常重要,它保證了持久化策略不會混入商務邏輯代碼,反之亦然。這種分離的好處就在於你的代碼將更加容易維護,因為它允許物件模型的演化不依賴於資料庫設計。
雖然MyBatis關注的主要是持久層,但理解應用程式的整體架構中的每個層仍然是很重要的。 雖然通過分層設計可以將關注點分離,從而將對任何一種特定實現的依賴都降到最低(甚至沒有),但如果你認為這樣就可以不管其他層的存在,不顧與其他層的互動,那就太天真了。不論應用程式設計得多麼完美,你都必須明白層與層之間一定存在某些間接的行為關聯。以下各節將 討論應用程式的各個層以及MyBatis與這些層的關係。
業務物件模型
業務對象是一個應用程式的所有其他部分的基礎。它是問題域在物件導向方法學中的一種表現,因此構成業務物件模型的各個類有時也被稱為領域類(domain class)。所有其他層都使用業務物件模型來表現資料和執行某些特定的商務邏輯功能。
應用程式的設計者們通常都是從業務物件模型的設計開始的。即使從較高的層次上看,業務物件模型中定義的各個類也都來源於我們的問題域中的名詞。隨著應用程式越來越複雜,類代表更抽象的概念。
業務物件模型類中當然也可能包括一些邏輯,但它們決不能包含任何用於訪問其他層(特別是表現層和持久層)的代碼。此外,這個業務物件模型絕對不能依賴於其他任何一層。其他層可 以使用業務物件模型——但永遠不能反過來。
像MyBatis這樣的持久層通常會使用商務邏輯對象來表現儲存在資料庫中的資料。業務對象模 型中的這些領域類將成為持久化方法(persistence method)的參數和傳回值。也正是因為這個原因,這些類有時也被稱為資料轉送類(data transfer object, DTO)。雖然資料轉送並不是它們唯 一的作用,但從持久化架構的角度看,這個名字還是相當合適的。
系列文章:
MyBatis知多少(1)
MyBatis知多少(2)
MyBatis知多少(3)
MyBatis知多少(4)MyBatis的優勢
MyBatis知多少(4)業務物件模型