程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> 網頁編程 >> JSP編程 >> 關於JSP >> 在ssh框架中service,action,jsp,formbeam,dao的調用順序

在ssh框架中service,action,jsp,formbeam,dao的調用順序

編輯:關於JSP

sp發起請求。     actionform封裝請求參數。 action接受請求,並接受封裝好的actionfrom action調用service。 service經過業務邏輯處理之後隨後調用DAO(或者直接在service中實現對數據的CRUD操作) DAO對數據庫進行CRUD。 1,dao和service對應   一般情況下,Hibernate DAO只操作一個POJO(簡單的Java對象,實際就是普通JavaBeans)對象,因此一個DAO對應一個POJO對象。 Service層是為了處理包含多個POJO對象(即對多個表的數據操作)時,進行事務管理(聲明式事務管理)。Service層(其接口的實現類)被注入多個DAO對象,以完成其數據操作。   2, Service之有無    這一點我的看法未必正確,我的腦海現在有兩種構建業務層的模式:    模式1是Service + DAO,即DAO中只做CRUD及類似的簡單操作(稱之為功能點,不包含業務邏輯),Service中通過調用一個或多個DAO中的功能點來組合成為業務邏輯.Service的數量應該由功能模塊來決定。    在這種模型中業務邏輯是放在Service中的,事務的邊界也應該在Service中控制. 當然,直接在Service中控制事務會引入非業務邏輯的代碼,幸好Spring的AOP可以解決這個問題,這也是引入Spring的原因之一.    如果說到缺點,就在於對某些對象的操作就是簡單的CRUD,Service層顯得累贅. 模式2是Service + BO, 而BO = DAO + 業務方法, 在原先DAO的基礎上添加業務方法,形成BO對象。需要注意的是BO中的業務方法往往是針對一個實體對象的,如果需要跨越多個實體對象,則方法應該放在 Service中。    舉例來說,一個簡單的銀行帳戶管理系統,創建帳戶這個BO對象,裡面可以有修改密碼,取錢等業務方法(不難看出,這些方法都只對單個帳戶對象進行操作)。現在需要添加一個轉賬方法,就應該放在Service中。    這裡Service和BO的關系是什麼樣的呢?再舉一例:以國家行政機關為例:糧食局負責收糧,賣種子等,建設部負責審批土地買賣,建設公路等,這都是行政部分份內的事兒。突然某地發了水災,救災時需要糧食局開倉放糧,建設部修建臨時房屋,如何協調兩個部門?就需要成立專門的救災委員會,由救災委員會出面對兩個部分的資源進行調撥。這裡兩個部分就是BO,而救災委員會就是Service。不知我的意思是否表達准確了,呵呵。 模式1的在劃分Service和DAO時界限清晰,但會帶來一些無必要的代碼。    模式2的劃分相對復雜,然而可以提高編碼效率。    當然小規模的應用中,沒有Service,完全是DAO或BO也是可以接受的。   3,Service和DAO的接口之有無    接口是一種契約,它可以有多種實現。所以接口之有無取決於具體實現是否需要多樣化。如果鐵定一種DAO或一種Service只有一種實現,那麼抽象出接口的意義不大。然而一些大型應用或許需要DAO和Service的多種實現(比如上面例子中的帳戶DAO,可能需要一種Hibernate實現、一種CMP 實現和一種JDO實現),為了向上一層隱藏具體實現類,需要采用接口。    隱藏具體實現類的創建過程,這有兩種方法:一是實用工廠方法,代價是代碼量大(每個DAO和Service一個工廠)。二是使用Spring的IoC,實現依賴注入,不需要寫額外的代碼,這也是引入Spring的理由之二。   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層因為耦合度比較高,因而要結合在一起開發,但是也可以看作一個整體獨立於前兩個層進行開發。這樣,在層與層之前我們只需要知道接口的定義,調用接口即可完成所需要的邏輯單元應用,一切顯得非常清晰簡單。www.2cto.com   DAO設計的總體規劃需要和設計的表,和實現類之間一一對應。   DAO層所定義的接口裡的方法都大同小異,這是由我們在DAO層對數據庫訪問的操作來決定的,對數據庫的操作,我們基本要用到的就是新增,更新,刪除,查詢等方法。因而DAO層裡面基本上都應該要涵蓋這些方法對應的操作。除此之外,可以定義一些自定義的特殊的對數據庫訪問的方法。   Service邏輯層設計   Service層是建立在DAO層之上的,建立了DAO層後才可以建立Service層,而Service層又是在Controller層之下的,因而Service層應該既調用DAO層的接口,又要提供接口給Controller層的類來進行調用,它剛好處於一個中間層的位置。每個模型都有一個Service接口,每個接口分別封裝各自的業務處理方法。   在DAO層定義的一些方法,在Service層並沒有使用,那為什麼還要在DAO層進行定義呢?這是由我們定義的需求邏輯所決定的。DAO層的操作 經過抽象後基本上都是通用的,因而我們在定義DAO層的時候可以將相關的方法定義完畢,這樣的好處是在對Service進行擴展的時候不需要再對DAO層進行修改,提高了程序的可擴展性。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved