JAVA分層結構和各層級的呼叫關係
-
DAO層
主要任務:做資料持久層的工作,負責與資料庫進行聯絡的一些任務都封裝在此。
DAO層的設計:首先是設計DAO層的介面,然後再Spring的配置檔案中定義此介面的實現類,然後就可以在模組中呼叫此介面來進行資料業務的處理,而不用關心此介面的具體實現類是哪一個,顯得結構非常清晰。DAO設計的總體規劃需要和設計的表,和實現類之間一一對應。
DAO層所定義的接口裡的方法,主要是增添改查,以及一些自定義的特殊的對資料庫訪問的方法。
配置:DAO層的資料來源配置,以及有關資料庫連線的引數都在Spring的配置檔案中進行配置。
-
Service層
主要任務
Service層的設計:首先設計介面,再設計實現的類,接著在Spring的配置檔案中配置起實現的關聯。
優點:封裝Service層的業務邏輯有利於通用的業務邏輯的獨立性和重複利用性,程式顯得非常簡潔。
這樣我們就可以在應用中呼叫Service介面來進行業務處理。Service層的業務實現,具體要呼叫到已定義的DAO層的介面。
-
Controller層
主要任務:負責具體的業務模組流程的控制,在此層裡要呼叫Service層的介面來控制業務流程。
配置:控制的配置也同樣在Spring的配置檔案中。
具體實現:
-
View層
主要任務:View層與Controller層介面緊密,需要系統開發。View表示層、主要負責前臺JSP頁面的表示。
概述而言:DAO層和Service層可以單獨開發,互相的耦合度很低,可以完全獨立進行,這樣的一種模式在開發大專案中尤其有有事。Controller和View層耦合度較高,因此要結合在一起開發,但是也可以看做一個整體獨立於前兩個層進行開發。這樣,在層與層之間,我們只需要介面的定義,呼叫介面即可完成所需要的邏輯單元應用。
Service層是建立在DAO層之上的,建立了DAO層後才可以建立Service層,而Service層又在Controller層之下的,因而Service層應該既呼叫DAO層的介面,又要提供介面給Controller層的類來進行呼叫,它剛好處於一箇中間層的位置。每個模型都有一個Service介面,每個介面分別封裝各自的業務處理方法。
在DAO層定義的一些方法,在Service層並沒有使用,那為什麼還要在DAO層進行定義呢?這是由我們定義的需求邏輯所決定的。DAO層的操作 經過抽象後基本上都是通用的,因而我們在定義DAO層的時候可以將相關的方法定義完畢,這樣的好處是在對Service進行擴充套件的時候不需要再對DAO層進行修改,提高了程式的可擴充套件性。
總結:
個人理解DAO面向表,Service面向業務。後端開發時先資料庫設計出所有表,然後對每一張表設計出DAO層,然後根據具體的業務邏輯進一步封裝DAO層成一個Service層,對外提供成一個服務。
面向介面程式設計。表示層呼叫控制層,控制層呼叫業務層,業務層呼叫資料訪問層。
Dao層設計與設計的資料庫表,和實現類(對應的Entity或者JavaBean)一一對應。
View層與Controller層結合緊密,需要二者結合協同開發。Service層、Dao層和其他層次耦合很低,完全可以單獨開發。
-------------------------------------------------------------
各層級的呼叫關係
顯示層——控制層——服務層——資料訪問層——持久層——資料層,以ssh為例,
就是顯示層jsp——控制層saction——服務層service——資料訪問層dao——持久層hibernante——資料層mysql
顯示層:人接互動,主要用於資料的展示和資料的錄入
控制層:總指揮,接受使用者提交的請求,根據請求的引數呼叫響應的服務類和需展示的顯示層
服務層:負責業務邏輯處理,過程中需要對資料庫進行操作的話,不親自動手,通過呼叫dao來實現
資料訪問層:顧名思義,就是對資料物件進行增刪改查操作
持久層:負責把資料物件持久化到資料庫
資料層:指資料庫這個層面。