在ssh框架中service,action,jsp,formbeam,dao的調(diào)用順序

jsp發(fā)起請求。actionform封裝請求參數(shù)。action接受請求，并接受封裝好的actionfromaction調(diào)用service。service經(jīng)過業(yè)務(wù)邏輯處理之后隨后調(diào)用DAO（或者直接在service中實現(xiàn)對數(shù)據(jù)的CRUD操作）DAO對數(shù)據(jù)庫進(jìn)行CRUD。1，dao和service對應(yīng)一般情況下,HibernateDAO只操作一個POJO（簡單的Java對象，實際就是普通JavaBeans）對象，因此一個DAO對應(yīng)一個POJO對象。Service層是為了處理包含多個POJO對象（即對多個表的數(shù)據(jù)操作）時，進(jìn)行事務(wù)管理（聲明式事務(wù)管理）。Service層（其接口的實現(xiàn)類）被注入多個DAO對象，以完成其數(shù)據(jù)操作。2,Service之有無這一點(diǎn)我的看法未必正確,我的腦海現(xiàn)在有兩種構(gòu)建業(yè)務(wù)層的模式：模式1是Service+DA。，即DAO中只做CRUD及類似的簡單操作（稱之為功能點(diǎn)，不包含業(yè)務(wù)邏輯）,Service中通過調(diào)用一個或多個DAO中的功能點(diǎn)來組合成為業(yè)務(wù)邏輯.Service的數(shù)量應(yīng)該由功能模塊來決定。在這種模型中業(yè)務(wù)邏輯是放在Service中的,事務(wù)的邊界也應(yīng)該在Service中控制.當(dāng)然，直接在Service中控制事務(wù)會引入非業(yè)務(wù)邏輯的代碼，幸好Spring的AOP可以解決這個問題，這也是引入Spring的原因之一.如果說到缺點(diǎn)，就在于對某些對象的操作就是簡單的CRUD,Service層顯得累贅.模式2是Service+BO,而BO=DAO+業(yè)務(wù)方法，在原先DAO的基礎(chǔ)上添加業(yè)務(wù)方法，形成BO對象。需要注意的是BO中的業(yè)務(wù)方法往往是針對一個實體對象的，如果需要跨越多個實體對象，則方法應(yīng)該放在Service中。舉例來說，一個簡單的銀行帳戶管理系統(tǒng)，創(chuàng)建帳戶這個BO對象，里面可以有修改密碼，取錢等業(yè)務(wù)方法（不難看出，這些方法都只對單個帳戶對象進(jìn)行操作）。現(xiàn)在需要添加一個轉(zhuǎn)賬方法，就應(yīng)該放在Service中。這里Service和BO的關(guān)系是什么樣的呢？再舉一例：以國家行政機(jī)關(guān)為例：糧食局負(fù)責(zé)收糧，賣種子等，建設(shè)部負(fù)責(zé)審批土地買賣，建設(shè)公路等，這都是行政部分份內(nèi)的事兒。突然某地發(fā)了水災(zāi)，救災(zāi)時需要糧食局開倉放糧，建設(shè)部修建臨時房屋，如何協(xié)調(diào)兩個部門？就需要成立專門的救災(zāi)委員會，由救災(zāi)委員會出面對兩個部分的資源進(jìn)行調(diào)撥。這里兩個部分就是BO，而救災(zāi)委員會就是Service。不知我的意思是否表達(dá)準(zhǔn)確了，呵呵。模式1的在劃分Service和DAO時界限清晰，但會帶來一些無必要的代碼。模式2的劃分相對復(fù)雜，然而可以提高編碼效率。當(dāng)然小規(guī)模的應(yīng)用中，沒有Service，完全是DAO或BO也是可以接受的。3,Service和DAO的接口之有無接口是一種契約，它可以有多種實現(xiàn)。所以接口之有無取決于具體實現(xiàn)是否需要多樣化。如果鐵定一種DAO或一種Service只有一種實現(xiàn)，那么抽象出接口的意義不大。然而一些大型應(yīng)用或許需要DAO和Service的多種實現(xiàn)（比如上面例子中的帳戶DAO,可能需要一種Hibernate實現(xiàn)、一種CMP實現(xiàn)和一種JDO實現(xiàn)），為了向上一層隱藏具體實現(xiàn)類，需要采用接口。隱藏具體實現(xiàn)類的創(chuàng)建過程，這有兩種方法：一是實用工廠方法，代價是代碼量大（每個DAO和Service一個工廠）。二是使用Spring的IoC，實現(xiàn)依賴注入，不需要寫額外的代碼，這也是引入Spring的理由之二。DAO層：DAO層主要是做數(shù)據(jù)持久層的工作，負(fù)責(zé)與數(shù)據(jù)庫進(jìn)行聯(lián)絡(luò)的一些任務(wù)都封裝在此，DAO層的設(shè)計首先是設(shè)計DAO的接口，然后在Spring的配置文件中定義此接口的實現(xiàn)類，然后就可在模塊中調(diào)用此接口來進(jìn)行數(shù)據(jù)業(yè)務(wù)的處理，而不用關(guān)心此接口的具體實現(xiàn)類是哪個類，顯得結(jié)構(gòu)非常清晰，DAO層的數(shù)據(jù)源配置，以及有關(guān)數(shù)據(jù)庫連接的參數(shù)都在Spring的配置文件中進(jìn)行配置。Service層：Service層主要負(fù)責(zé)業(yè)務(wù)模塊的邏輯應(yīng)用設(shè)計。同樣是首先設(shè)計接口，再設(shè)計其實現(xiàn)的類，接著再Spring的配置文件中配置其實現(xiàn)的關(guān)聯(lián)。這樣我們就可以在應(yīng)用中調(diào)用Service接口來進(jìn)行業(yè)務(wù)處理。Service層的業(yè)務(wù)實現(xiàn)，具體要調(diào)用到已定義的DAO層的接口，封裝Service層的業(yè)務(wù)邏輯有利于通用的業(yè)務(wù)邏輯的獨(dú)立性和重復(fù)利用性，程序顯得非常簡潔。Controller層:Controller層負(fù)責(zé)具體的業(yè)務(wù)模塊流程的控制，在此層里面要調(diào)用Serice層的接口來控制業(yè)務(wù)流程，控制的配置也同樣是在Spring的配置文件里面進(jìn)行，針對具體的業(yè)務(wù)流程，會有不同的控制器，我們具體的設(shè)計過程中可以將流程進(jìn)行抽象歸納，設(shè)計出可以重復(fù)利用的子單元流程模塊，這樣不僅使程序結(jié)構(gòu)變得清晰，也大大減少了代碼量。View層此層與控制層結(jié)合比較緊密，需要二者結(jié)合起來協(xié)同工發(fā)。View層主要負(fù)責(zé)前臺jsp頁面的表示，DAO層，Service層這兩個層次都可以單獨(dú)開發(fā)，互相的耦合度很低，完全可以獨(dú)立進(jìn)行，這樣的一種模式在開發(fā)大項目的過程中尤其有優(yōu)勢，Controller，View層因為耦合度比較高，因而要結(jié)合在一起開發(fā)，但是也可以看作一個整體獨(dú)立于前兩個層進(jìn)行開發(fā)。這樣，在層與層之前我們只需要知道接口的定義，調(diào)用接口即可完成所需要的邏輯單元應(yīng)用，一切顯得非常清晰簡單。DAO設(shè)計的總體規(guī)劃需要和設(shè)計的表，和實現(xiàn)類之間一一對應(yīng)。DAO層所定義的接口里的方法都大同小異，這是由我們在DAO層對數(shù)據(jù)庫訪問的操作來決定的，對數(shù)據(jù)庫的操作，我們基本要用到的就是新增，更新，刪除，查詢等方法。因而DAO層里面基本上都應(yīng)該要涵蓋這些方法對應(yīng)的操作。除此之外，可以定義一些自定義的特殊的對數(shù)據(jù)庫訪問的方法。Service邏輯層設(shè)計Service層是建立在DAO層之上的，建立了DAO層后才可以建立Service層，而Service層又是在Controller層之下的，因而Service層應(yīng)該既調(diào)用DAO層的接口，又要提供接口給Controller層的類來進(jìn)行調(diào)用，它剛好處于一個中間層的位置。每個模型都有一個Service接口，每個接口分別封裝各自的業(yè)務(wù)處理方法。在DAO層定義的一些方法，在Service層并沒