回覆列表
-
1 # 唯一胡小然
-
2 # 急速馬力快de原始碼控
一個非常好的問題。三層或者多層架構的核心思想是分層,不同粒度和維度都有應用。
一,系統架構常見的動靜分離、資料中臺、微服務在一定程度上都是將系統實現進行分層解耦,從而使得系統表現為不同的層次,比如典型的前端頁面展示、介面服務、資料儲存。
二,前端架構以典型的Ant Design開發資訊管理系統為例,將前端實現分為Page、Model、Service三層,Page展示頁面響應使用者操作,Model儲存資料,Service處理業務邏輯、呼叫後臺服務介面。
三,後端架構在後端開發中,仍然會採用分層架構。比如常用的Java + Spring Boot框架開發Web服務時,有Controller,Service,Entity,分別封裝
-
3 # 優就業浙江IT培訓
資料訪問層:
資料訪問層又稱為DAL層,有時候也稱為是持久層,其功能主要是負責資料庫的訪問,進行讀取資料和傳遞資料。
簡單的說,就是透過DAL對資料庫進行的SQL語句等操作,實現對資料表的Select(查詢),Insert(插入),Update(更新),Delete(刪除)。如果要加入ORM的元素,那麼就會包括物件和資料表之間的mapping,以及物件實體的持久化。。
業務邏輯層:業務邏輯層負責系統領域業務的處理,負責邏輯性資料的生成、處理及轉換。對所輸入的邏輯性資料的正確性及有效性負責,但對輸出的邏輯性資料及使用者性資料的正確性不負責,對資料的呈現樣式不負責。
用於做一些有效性驗證的工作,以更好地保證程式執行的健壯性。如完成資料新增、修改和查詢業務等;不允許指定的文字框中輸入空字串,資料格式是否正確以及資料型別驗證;使用者許可權的合法性判斷等;透過以上的諸多判斷以決定是否將操作繼續向後傳遞,儘量保證程式的正常執行。
表示層:負責整個頁面的呈現樣式。
我覺得這個三層架構是個不同階段理解不同的概念。
我們最開始做專案的時候,對於java而言就是servlet、jsp之流(像.net等應該就是asp或者asp.net),甚至直接將業務邏輯寫在jsp頁面裡面,沒有什麼層的概念,一個jsp就打天下了。開發時爽的不行,連上資料庫,curd搞起來,資料頁面一繫結,我們就萬事大吉了,幹他什麼業務變更,業務擴充套件呢,那是leader的事,和我有什麼關係。
然後悲劇就開始發生了,我們的產品很快找到了老大,我們最近業務要擴充套件了,我們一想這還不簡單,直接在頁面上加連結,加新的jsp頁面就行了,說幹就幹,繼續在jsp裡面翻雲覆海,很快搞定了,這樣的事情在一年內發生了百次以上,之後產品找到老大,說我們的計算方式變化了,頁面不變,但是資料都不對了,我們需要重寫下業務計算的方式,一部分還是原來的邏輯,一部分變更成新的,這下我們就犯難了,這上百個jsp,每個裡面都是大量的邏輯,資料庫查詢,修改等操作,這怎麼把業務按資料拆分開啊,最終直接刪程式碼跑路嘍。。。
剛才廢了好多話就是想描述下在三層架構沒有流行起來前開發的模式和弊端,工筆不好,大家見諒吧,總體想表達的也就是三層架構為什麼要出現,解決的是什麼問題。
我先上定義:
三層架構(3-tier architecture) 通常意義上的三層架構就是將整個業務應用劃分為:介面層(User Interface layer)、業務邏輯層(Business Logic Layer)、資料訪問層(Data access layer)。區分層次的目的即為了“高內聚低耦合”的思想。在軟體體系架構設計中,分層式結構是最常見,也是最重要的一種結構。微軟推薦的分層式結構一般分為三層,從下至上分別為:資料訪問層(又稱為持久層)、業務邏輯層(又或稱為領域層)、表示層。
表示層(UI層): 表示層也稱為介面層,位於最外層(最上層),離使用者最近。用於顯示資料和接收使用者輸入的資料,為使用者提供一種互動式操作的介面。
業務邏輯層(BLL層): 負責關鍵業務的處理和資料的傳遞。複雜的邏輯判斷和涉及到資料庫的資料驗證都需要在此做出處理。主要是針對具體的問題的操作,也可以理解成對資料層的操作,對資料業務邏輯處理,如果說資料層是積木,那邏輯層就是對這些積木的搭建。
資料訪問層(DAL層): 主要負責對資料庫的直接訪問,為業務邏輯層提供資料,根據傳入的值來操作資料庫,增、刪、改、查。
說白了就是一句話,把上面我說的那100多個jsp頁面裡面的業務邏輯抽取出來,按角色分成上面的三層。
這樣就可以讓我們的程式碼達到“高內聚,低耦合”的目的,每層需要修改不會影響其他層,便於發現和改正BUG。還有比較關鍵的一點是程式碼的複用和勞動成本的減少,分層的最理想化的結果是實現層與層之間的互不依賴的內部實現,所謂的即插即用!
我覺得最重要的一點是便於團隊開發過程中的管理,三層架構使得合作開發成為可能,由於各層相互獨立,一個小組只需負責一小塊就可以。結構化的程式設計方法面對大型的專案會感到力不從心,因為結構化設計必定會使程式變的錯綜複雜。邏輯主要在BLL層,就使得UI層也就是客戶端不承擔太多的職責,即使更新業務邏輯,也無需修改客戶端,不用重新部署。
擦,寫了這麼多才發現我回答錯了主題,題主想問的是如何更好的體現,哎算了,不改了,發出去就算幫題主加個熱度吧....