<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>

新聞中心

EEPW首頁(yè) > 設計應用 > 設計模式在業(yè)務(wù)邏輯層中的應用

設計模式在業(yè)務(wù)邏輯層中的應用

作者: 時(shí)間:2009-09-06 來(lái)源:網(wǎng)絡(luò ) 收藏
引言

傳統軟件應用系統一般采用3層應用框架,業(yè)務(wù)邏輯層代碼中混雜各種調用語(yǔ)句,嚴重影響系統的可擴展性、可復用性和可維護性。

設計可復用的面向對象軟件有很多難點(diǎn)。如找到相關(guān)對象;以適當的粒度將其歸類(lèi);定義類(lèi)的接口和繼承層次,建立對象之間的基本關(guān)系;要對現在的問(wèn)題有針對性,同時(shí)對將來(lái)的問(wèn)題和需求也有足夠的通用性;避免重復設計或盡可能少做重復設計等。

采用可有效解決這些難點(diǎn),從而簡(jiǎn)單方便地復用成功的設計和體系結構。通過(guò)采用,能大大提高系統的可擴展性、可重用性和可維護性,并能降低系統開(kāi)發(fā)難度,提高開(kāi)發(fā)效率。已成為當前乃至今后軟件工程研究領(lǐng)域的一大熱點(diǎn),并被認為是繼OOP技術(shù)之后的又一重大突破。

首先簡(jiǎn)要介紹設計模式,然后分析傳統3層架構開(kāi)發(fā)模型的優(yōu)缺點(diǎn),充分考慮系統的可擴展性,可復用性,可維護性,從軟件設計模式角度提出改進(jìn)方法,并給出研究實(shí)例。

2 設計模式

每一個(gè)模式描述一個(gè)在不斷重復發(fā)生的問(wèn)題,以及該問(wèn)題解決方案的核心。這樣就能多次使用該方案而不必重復勞動(dòng)。設計模式是面向對象軟件設計過(guò)程中記錄的知識和經(jīng)驗,用一系列類(lèi)結構和對象來(lái)具體描述其含義。設計模式通過(guò)復用面向對象設計的解決方案,從而更加簡(jiǎn)單方便地復用成功的設計和體系結構,將已證實(shí)的技術(shù)表述成設計模式也會(huì )使新系統開(kāi)發(fā)者更加容易理解其設計思路。設計模式可幫助設計者做出有利于系統復用選擇,避免損害系統復用性,通過(guò)提供一個(gè)顯式類(lèi)和對象作用關(guān)系及它們之間潛在聯(lián)系說(shuō)明規范,設計模式甚至能夠提高已有系統的文檔管理和系統維護的有效性。設計模式確定所包含的類(lèi)和實(shí)例及其角色、協(xié)作方式、職責分配。通過(guò)刻畫(huà)部件靜態(tài)和動(dòng)態(tài)結構及其之間的合作關(guān)系,設計模式成功應用于解決商業(yè)數據處理、電子通信、圖形用戶(hù)界面、、分布式通信軟件等軟件構造中。

3 傳統的3層架構開(kāi)發(fā)模型

目前,在Internet/Intranet環(huán)境中,企業(yè)級的應用軟件系統大多采用3層應用框架:表示層、業(yè)務(wù)邏輯層和數據層(圖1)。在這種層次結構的軟件框架中。每層為其上一層提供服務(wù)(服務(wù)提供者),并作為其下一層的客戶(hù)(服務(wù)消費者),內部的層只對相鄰的層可見(jiàn),從而構成一個(gè)具有可移植性、可擴充性的兼容平臺。

本文引用地址:http://dyxdggzs.com/article/261221.htm
但也存在顯著(zhù)的缺點(diǎn):在開(kāi)發(fā)多個(gè)應用軟件系統的過(guò)程中,不同的應用軟件系統之間耦合度不是很好;層與層之間代碼混亂;訪(fǎng)問(wèn)的方式不同,如JDBC, Hibernate或JDO,因此,在各種數據庫之間移植就需修改很多地方,業(yè)務(wù)邏輯層也需跟著(zhù)修改,不能采用一致的編程模型,系統的可復用性、可維護性不是很理想。

4 改進(jìn)的4層架構開(kāi)發(fā)模型

基于上述分析,為提高軟件的開(kāi)發(fā)效率,這里從設計模式角度出發(fā),提出把業(yè)務(wù)邏輯層進(jìn)一步分出一層,單獨形成一個(gè)數據接口層。數據接口層屏蔽各種底層數據庫之間的差異,負責與底層數據庫之間的連接。形成4層軟件體系結構框架,從上到下依次是:表示層、業(yè)務(wù)邏輯層、數據接口層、數據層,如圖2所示。表示層是應用軟件進(jìn)行人機交互的接口;業(yè)務(wù)邏輯層負責處理用戶(hù)的業(yè)務(wù)請求;數據接口層負責與底層數據庫之間的交互;數據層則負責存儲數據。

4.1 設計模式

數據接口層采用數據訪(fǎng)問(wèn)對象(Data Access Ob-iect)模式。該模式實(shí)際是Adapter模式和Bridge模式的混合體,對象提供數據庫訪(fǎng)問(wèn)的基本操作,如增加、刪除、修改、查詢(xún)等。 DAO層以面向對象的方式封裝數據庫操作。DAO組件完全專(zhuān)注于數據訪(fǎng)問(wèn)實(shí)現,業(yè)務(wù)層代碼無(wú)須關(guān)心底層數據庫訪(fǎng)問(wèn)的實(shí)現,從而降低了層之間的耦合。

DAO設計模式的優(yōu)點(diǎn):

(1)DAO模式抽象出數據訪(fǎng)問(wèn)方式,業(yè)務(wù)邏輯層訪(fǎng)問(wèn)數據源時(shí)完全感覺(jué)不到數據源的存在。軟件工廠(chǎng)中有一條很重要的法則:一個(gè)對象對其他對象的了解越少越好,了解越少就意味著(zhù)依賴(lài)越少,可復用性越高。

(2)DAO將數據訪(fǎng)問(wèn)集中在獨立的一層,因為所有的數據訪(fǎng)問(wèn)都由DAO代理,這層獨立的DAO將數據訪(fǎng)問(wèn)的實(shí)現和系統的其余部分剝離,將數據訪(fǎng)問(wèn)集中,使得系統更具可維護性。

(3)DAO降低了業(yè)務(wù)邏輯層的復雜度。DAO管理復雜的數據訪(fǎng)問(wèn),從而簡(jiǎn)化了業(yè)務(wù)邏輯層。所有與數據訪(fǎng)問(wèn)的實(shí)現有關(guān)的代碼(例如SOL語(yǔ)言等)都不寫(xiě)在業(yè)務(wù)邏輯層里,業(yè)務(wù)邏輯層可集中處理業(yè)務(wù)邏輯,提高了代碼的可讀性和生產(chǎn)率。

上一頁(yè) 1 2 下一頁(yè)

關(guān)鍵詞: 設計模式 DAO 數據庫

評論


相關(guān)推薦

技術(shù)專(zhuān)區

關(guān)閉
国产精品自在自线亚洲|国产精品无圣光一区二区|国产日产欧洲无码视频|久久久一本精品99久久K精品66|欧美人与动牲交片免费播放
<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>