多層架構簡述

2021-04-13 03:26:31 字數 1321 閱讀 7139

使用多層架構進行系統開發是現今系統設計的流行趨勢。通過分解業務細節,將不同的功能**分散開來,更利於系統的設計和開發,同時為可能的變更提供了更小的單元。

以下就是乙個典型的多層體系結構圖。

首先我們以「訂單(order)」為例,進行乙個簡單的業務分解。

1. 訂單自然包括訂單的內容(orderinfo),其中有諸如訂單編號、商品名稱、數量,以及金額等資訊。

2. 有了訂單資訊,我們還需要乙個儲存訂單的場所,那麼自然需要有個操作讀寫的物件(orderaccess)。

3. 為了外界能進行相關的訂單操作,我們還需要有個業務邏輯物件(order),它提供建立新訂單,向訂單插入/刪除商品,儲存訂單等操作。

通過上面的分析,我們基本上可以將乙個業務邏輯完整地分割為:

業務實體 ---> orderinfo

資料訪問 ---> orderaccess

業務邏輯 ---> order

基於系統架構考慮,我們將這些物件分別放置在不同的邏輯單元中,這些邏輯單元就組成了「多層」。

業務實體層(model) ---> 業務實體 ---> orderinfo

資料訪問層(dal) ---> 資料訪問 ---> orderaccess

業務邏輯層(bll) ---> 業務邏輯 ---> order

同樣以上面訂單為例,我們進一步講述各層物件的實現細節。

1. 客戶基本上只依賴於 order 和 orderinfo,通過他們就可以操作業務的全部,它並不關心業務儲存等細節。

2. 大多數時候我們會將 orderaccess 設計成 internal protected 方式,orderaccess 可以是乙個抽象類或者介面。我更習慣於將其實現為抽象類,因為某些方法是呼叫其他方法來實現的,抽象類的設計可以減少實現類的**數量。另外將該抽象類設計成工廠方法模式,通過 ioc 或者 "配置反射" 來獲得具體的實現類,可以減少層之間的耦合,也便於資料系統的替換。

3. order 多數時候可以實現為 singleton 或者靜態類,它只是提供了一系列的方法來操作某些邏輯,通過接受 orderinfo 引數來獲取資訊。其本身無需儲存任何狀態。如果需要實現購物車,只需將 orderinfo 儲存到 session 之中即可。

通過上面的例子,我們還可以發現多層的另外乙個好處就是更利於團隊協作開發。架構設計人員無需考慮具體的資料庫實現**,而將設計重點放在業務層面;資料庫開發人員自然也可將重心放在資料庫訪問優化上。團隊成員之間不再是一人負責乙個業務模組,不再有了 n 個資料訪問類,不再有 n 種不同的物件模式等等。從傳統的 "瓦罐作坊" 演變為 "工業流水線",更利於根據技術能力和業務熟悉度的差別來劃分不同的角色。

推薦:多層 + ioc 絕對是個不錯的選擇。  

多層架構簡述

分類 多層架構 2007 06 20 14 47 2247人閱讀收藏 舉報 資料庫ioc 架構設計 儲存session作業 使用多層架構進行系統開發是現今系統設計的流行趨勢。通過分解業務細節,將不同的功能 分散開來,更利於系統的設計和開發,同時為可能的變更提供了更小的單元。以下就是乙個典型的多層體系...

c 多層架構

三層結構 表現層,業務邏輯層,資料訪問層。功能 表現層 資料的現實和接收使用者輸入的資料 為使用者提供一種互動式操作的介面 業務邏輯層 處理資料 它處於表現層與資料訪問層之間,起到了資料互動中承上啟下的作用。資料訪問層 持久層 實現了對資料的儲存和讀取操作。它還負責想業務邏輯層提供資料和修改資料的操...

多層架構 轉載

多層結構就像多個人,分別不同負責各自的工作。該知道自己知道的,不該知道自己不知道的。別八卦,別打聽不該自己知道的事。表示層 不應該知道的 不應該看到物理的資料儲存。不應該有connection strings,connections,commands或者類似。應該知道的 應該知道主要模組。業務邏輯層...