前部分摘錄自:http://blog.csdn.net/zdwzzu2006/article/details/6053006
- DAO層:DAO層主要是做數據持久層的工作,負責與數據庫進行聯絡的一些任務都封裝在此,DAO層的設計首先是設計DAO的接口,然后在Spring的配置文件中定義此接口的實現類,然后就可在模塊中調用此接口來進行數據業務的處理,而不用關心此接口的具體實現類是哪個類,顯得結構非常清晰,DAO層的數據源配置,以及有關數據庫連接的參數都在Spring的配置文件中進行配置。
- Service層:Service層主要負責業務模塊的邏輯應用設計。同樣是首先設計接口,再設計其實現的類,接着再Spring的配置文件中配置其實現的關聯。這樣我們就可以在應用中調用Service接口來進行業務處理。Service層的業務實現,具體要調用到已定義的DAO層的接口,封裝Service層的業務邏輯有利於通用的業務邏輯的獨立性和重復利用性,程序顯得非常簡潔。
- Controller層:Controller層負責具體的業務模塊流程的控制,在此層里面要調用Serice層的接口來控制業務流程,控制的配置也同樣是在Spring的配置文件里面進行,針對具體的業務流程,會有不同的控制器,我們具體的設計過程中可以將流程進行抽象歸納,設計出可以重復利用的子單元流程模塊,這樣不僅使程序結構變得清晰,也大大減少了代碼量。
- View層 此層與控制層結合比較緊密,需要二者結合起來協同工發。View層主要負責前台jsp頁面的表示,
- DAO層,Service層這兩個層次都可以單獨開發,互相的耦合度很低,完全可以獨立進行,這樣的一種模式在開發大項目的過程中尤其有優勢,Controller,View層因為耦合度比較高,因而要結合在一起開發,但是也可以看作一個整體獨立於前兩個層進行開發。這樣,在層與層之前我們只需要知道接口的定義,調用接口即可完成所需要的邏輯單元應用,一切顯得非常清晰簡單。
- DAO設計的總體規划需要和設計的表,和實現類之間一一對應。
- DAO層所定義的接口里的方法都大同小異,這是由我們在DAO層對數據庫訪問的操作來決定的,對數據庫的操作,我們基本要用到的就是新增,更新,刪除,查詢等方法。因而DAO層里面基本上都應該要涵蓋這些方法對應的操作。除此之外,可以定義一些自定義的特殊的對數據庫訪問的方法。
- Service邏輯層設計
- Service層是建立在DAO層之上的,建立了DAO層后才可以建立Service層,而Service層又是在Controller層之下的,因而Service層應該既調用DAO層的接口,又要提供接口給Controller層的類來進行調用,它剛好處於一個中間層的位置。每個模型都有一個Service接口,每個接口分別封裝各自的業務處理方法。
- 在DAO層定義的一些方法,在Service層並沒有使用,那為什么還要在DAO層進行定義呢?這是由我們定義的需求邏輯所決定的。DAO層的操作 經過抽象后基本上都是通用的,因而我們在定義DAO層的時候可以將相關的方法定義完畢,這樣的好處是在對Service進行擴展的時候不需要再對DAO層進行修改,提高了程序的可擴展性。
在DAO層定義的一些方法,在Service層並沒有使用,那為什么還要在DAO層進行定義呢?這是由我們定義的需求邏輯所決定的。DAO層的操作 經過抽象后基本上都是通用的,因而我們在定義DAO層的時候可以將相關的方法定義完畢,這樣的好處是在對Service進行擴展的時候不需要再對DAO層進行修改,提高了程序的可擴展性。
DAO完成連接數據庫修改刪除添加等的實現細節,例如sql語句是怎么寫的,怎么把對象放入數據庫的。service層是面向功能的,一個個功能模塊比如說銀行登記並完成一次存款,UI要把請求給service層,然后service曾將這一個case分解成許多步驟調用底層的實現完成這次存款,dao就是下面那層。
dao就是把數據存起來,之所以service的方法會有雷同只不過是因為service得需求不是很復雜不用再service里面完成太多包裝或者處理過程可以直接調用dao的方法就完成的請求處理例如就要save一個對象,而這個對象是封裝好的,dao里面有個方法專門save封裝好的對象於是service的方法就僅僅調用一下就o了,函數簽名自然很像了service不能直接接觸持久層,而dao是持久層或者直接訪問持久層有的時候只是為了分層清楚,為了將來scale up的時候方便我們才把service和dao分開,其實沒必要分開的。
---------------------------------------------------------------
根據不同項目的復雜度來確定是否需要分層,如果是小項目的話,2層應該就夠了,分層是為了很好的解耦,和程序的可觀性,還有就是很好的項目分工,如果遇到某個客戶需要修改某個查詢結果集合,你需要修改的首先是dao的SQL,接着是service的相應調用方法來為VIEW服務, 如果是分層清楚的話,只需要在DAO中加一個方法,在SERVICE中改變起調用的方法接口,需要改動的不大,
-----------------------------------------------------------------
在用ssh進行開發中,一般情況下都是分為三層:web層spring層dao層,基本的流程是首先定義一個dao接口,然后去實現這個接口,在定義同類型的service接口(service接口與dao接口是完全一樣),再實現service接口,(這是是用dao接口去注入),然后web層在去調用service層。
DAO層的職責是純粹的數據操作,如果是hibernate,那就只需要類似getHibernateTemplate().save, update, delete, findyBy*這類的方法而service層是負責寫業務邏輯的,純粹的業務邏輯,其中的數據操作是通過注入的DAO實現的,但是業務是在這層。 如果你的service層與dao層代碼嚴重重復,這說明你的業務比較簡單。復雜業務這個結構的優勢就很明顯了。service層的作用是對dao取得的數據做操作更貼近於業務的實現 dao只是數據的增刪改查,對小型的應用來說,SSH 確實提高了開發成本和開發周期,但是卻有利於擴展和維護。
利用spring 的ioc 解偶使業務邏輯與持久層松偶合。
-----------------------------------------------------------------
分層並不一定是絕對的,具體的還是要根據項目實際情況來定,不是么?如果是理想狀態的話,恐怕在你的service層上面還要再多加一層的。但是你覺得有必要嗎?
實際上,對於小項目來說,直接通過dao來進行操作也不是不可以,搞得太復雜,也沒有必要。這是我的個人感覺。就好像po和dto一樣,有的人直接就將po傳到web層,有的還要加一個轉換,由dto進行數據傳遞。顯然后者實現更理想,但是你不覺得這樣很麻煩嗎。 微軟的。net號稱有11層(還是多少層來着,反正層很多),但是實際能分出多少層,還是根據開發者自己情況來定了。要注意代碼是死的,人是活的,不要死套框架,否則自己很可能也會陷入開發誤區。