建站
咨詢
售后
建站咨詢
新聞中心
當我們開發(fā)一個應用程序時，業(yè)務邏輯和數(shù)據持久化是兩個非常重要的部分。在進行數(shù)據持久化時，我們通常會選擇一個數(shù)據庫去存儲我們的數(shù)據。而在與數(shù)據庫進行交互時，我們則會使用層次結構不同的技術。其中一種常用的技術是DAO（Data Access Object），它是一種輕量級的數(shù)據訪問模式。
本文將會深入探討DAO的設計原理與實現(xiàn)，并介紹如何正確地應用DAO模式來增強我們程序的可維護性、擴展性和可重用性。
1. DAO模式的概述
DAO模式是一種將數(shù)據持久化的方法從業(yè)務邏輯中分離出來的設計模式。它的核心思想是將數(shù)據訪問和數(shù)據操作分離，將數(shù)據持久化層封裝到單獨的DAO中，實現(xiàn)了業(yè)務邏輯層與數(shù)據持久化層的解耦，使應用程序更加易于維護和擴展。
2. DAO模式的設計原則
在設計DAO模式時，我們需要遵循以下原則：
2.1 單一職責原則
每個DAO應該只包含一種實體的操作，并且不應包含其他實體的操作。例如，一個名為UserDAO的DAO應該只包含用戶實體的操作。
2.2 開放封閉原則
DAO應該支持未來的擴展，但不會修改現(xiàn)有代碼。
2.3 接口隔離原則
DAO應該只實現(xiàn)必需的接口，并且不應該實現(xiàn)不必要的接口。
2.4 依賴倒置原則
高級模塊應該依賴于抽象而不是實現(xiàn)。換句話說，DAO的實現(xiàn)應該來自于抽象類或接口，而不是具體的實現(xiàn)。
3. DAO模式的實現(xiàn)
DAO模式的核心是將數(shù)據訪問和數(shù)據操作分離。在實現(xiàn)DAO模式時，我們需要創(chuàng)建至少三個組件：實體類，DAO接口和DAO實現(xiàn)類。
3.1 實體類
實體類是指表示數(shù)據模型的類，通常包含了實體的各種字段，以及用于訪問和操作這些字段的方法。例如，我們可以創(chuàng)建一個名為User的實體類，它包含了用戶實體的所有字段及用于獲取和設置這些字段的方法。
“`java
public class User {
private int id;
private String name;
private int age;
// Getters and setters
}
“`
3.2 DAO接口
DAO接口是指用于定義DAO操作的接口，通常包含用于添加、刪除、更新和查找實體的方法。例如，我們可以創(chuàng)建一個名為UserDAO的接口，它包含了用于操作用戶實體的所有方法。
“`java
public interface UserDAO {
void addUser(User user);
void deleteUser(int id);
void updateUser(User user);
User getUser(int id);
}
“`
3.3 DAO實現(xiàn)類
DAO實現(xiàn)類是指用于執(zhí)行具體DAO操作的類，通常包含了數(shù)據庫操作的代碼。例如，我們可以創(chuàng)建一個名為UserDAOImpl的實現(xiàn)類，它包含了用于操作用戶實體的所有代碼。
“`java
public class UserDAOImpl implements UserDAO {
@Override
public void addUser(User user) {
// Insert user into the database
}
@Override
public void deleteUser(int id) {
// Delete user from the database
}
@Override
public void updateUser(User user) {
// Update user in the database
}
@Override
public User getUser(int id) {
// Get user from the database
return null;
}
}
“`
4. DAO模式的優(yōu)缺點
DAO模式提供了很多優(yōu)點，包括代碼的可維護性、可擴展性和可重用性等。
4.1 可維護性
DAO模式使應用程序的維護更加容易。由于數(shù)據持久化層和業(yè)務邏輯層分離，所以我們可以更加輕松地維護應用程序，并在需要時更改數(shù)據持久化層的實現(xiàn)。
4.2 可擴展性
DAO模式支持未來的擴展，而不需要修改現(xiàn)有代碼。如果我們需要添加新的功能，我們只需要添加新的DAO方法，而不需要修改現(xiàn)有的代碼。
4.3 可重用性
DAO模式使得數(shù)據訪問邏輯的重用更加容易。由于DAO模式中的數(shù)據訪問邏輯是抽象的，因此我們可以輕松地重用它，而不需要重寫現(xiàn)有的代碼。
然而，DAO模式也存在一些缺點。最主要的問題就是它增加了代碼的復雜度。由于我們需要創(chuàng)建多個類來實現(xiàn)DAO模式，因此代碼的組織和維護是一項挑戰(zhàn)。
5. DAO模式的應用場景
DAO模式通常適用于需要將數(shù)據訪問邏輯從業(yè)務邏輯中分離出來的應用程序。例如，當我們需要封裝數(shù)據源時，使用DAO模式是一種比較好的選擇。
除此之外，DAO模式還適用于需要增強代碼可維護性、擴展性和可重用性的應用程序。當我們需要在應用程序中添加新的功能時，我們可以輕松地添加新的DAO方法，以支持這些功能。
6. 結論
DAO模式是一種使用廣泛的輕量級數(shù)據訪問模式，可以將數(shù)據持久化層封裝到單獨的DAO中，實現(xiàn)了業(yè)務邏輯層與數(shù)據持久化層的解耦。在設計和實現(xiàn)DAO模式時，我們需要遵循單一職責原則、開放封閉原則、接口隔離原則以及依賴倒置原則等原則。DAO模式具有可維護性、可擴展性和可重用性等優(yōu)點，但它也存在代碼復雜度高的問題。DAO模式通常適用于需要封裝數(shù)據源、增強代碼可維護性、可擴展性和可重用性的應用程序。
成都網站建設公司-創(chuàng)新互聯(lián),建站經驗豐富以策略為先導10多年以來專注數(shù)字化網站建設,提供企業(yè)網站建設,高端網站設計,響應式網站制作,設計師量身打造品牌風格,熱線:028-86922220關于javabean和DAO模式
JavaBean是數(shù)據的承載體，負責把一組有邏輯的數(shù)據從一個層傳到另一個層。
DAO的出現(xiàn)是對持久層的變動的一個解決方案。
對于不同的持久介質(RDBMS、XML、ODBMS等)、不同的提供廠商(Oracle、Mysql等)提供的產品，進行持久化操作時，對于業(yè)務邏輯層應該是統(tǒng)一的，于是DAO模式就出現(xiàn)了。
對于同一個業(yè)務操作，例如添加一個用戶，請求到達業(yè)務層，只需調用DAO層的addUser()即可。而到底是怎么添加的、以及添加到哪里，是業(yè)務層不用關心的，也是不要關心的。
于是，持久層將利用業(yè)務層傳遞來的請求數(shù)據，即封裝了要添加的用戶信息JavaBean，添加到持久層：Oracle就要取序列，Mysql會自動增長，XML就要手動控制了。這些實現(xiàn)細節(jié)對業(yè)務邏輯層是一樣的效果。
但是DAO模式中也會有一些數(shù)據承載體，不過它們承載的不是業(yè)務數(shù)據，而是持久化操作的相關對象，例如DAO對象，DAO工廠，連接對象等。表面上看，這些也承載數(shù)據，但它實際是包含了內在的邏輯和操作。例如連接對象的打開和關閉，事務的回滾和提交等。
所以，嚴格意義上來說，它們不是純粹的JavaBean。純粹的JavaBean是只包含屬性和這些屬性對應的getter和setter。
JavaBean就是把簡單的POJO.
但是DAO是封狀操作數(shù)據庫等細節(jié)的.
spring mvc里面,為什么要單獨出來一個service層調用dao再傳給controller啊? 這樣設計有什么好處？
有些朋友可能會問為什么要分層呢？我本來可以在一個地方寫完的東西，非要散落在各個層中，都在一起不是挺好的嗎，而且開發(fā)效率也比較高啊~
跳來跳去的我腦子都暈啦。。。
這就是為什么有人會把所有的東西都扔在一個層里，比如controller層。。。
其實我們可以在jsp上把所有的邏輯以及數(shù)據庫操作,數(shù)據展示全部寫在一起，耦合在一起，這樣開發(fā)起來貌似更快，
但是維護性非常差，有朝一日想改一個小地方，牽一發(fā)而動全一身，隱患很高，無法快速定位問題察乎寬。
因此我們需要分層。
分層了之后，你理論上改了持久層的東西，邏輯層是不用變動的。
每個Dao類是跟每個表走，Dao的每個方法里就一個個的簡單sql，不包含任何業(yè)務邏輯，可以被不同的service復用和調用。
經過抽象后基本上都是通用的，因而我們在定義DAO層的時候可以將相關的方法定義完畢，
這樣的好處是在對Service進行擴展的時候不需要再對DAO層進行修改，提高了程序的可擴展性。
提高了程序的可擴展性。具體什么時候做這些操作，怎么做這些操作都由Service來處理。
（就像郭德綱的相聲里的一句話：“行了，你甭管了”）
而Service則不是，一個Service里可以會調用多個不同的dao，完成特定的業(yè)務邏輯，事務控制，
封裝Service層的業(yè)務邏輯有利于通用的業(yè)務邏輯的獨立性和重復利用性
同時，一個Service的方法也有可能被多個Controller的方法來調用。
邏輯出問題就在Service找問題，數(shù)據庫，sql有問題就在Dao層找問題，
參數(shù)解析錯誤，跳轉錯誤，就在Controller上找問題。
這樣快速定位問題，互不干擾。
–
分層架構（這里會延伸到更廣闊的架構）：
回頭項目玩大了，怎么辦？拆?。?！
具體可以搜一下：maven分模塊開發(fā)，怎么玩代碼依賴，怎么玩微服務，怎么玩SOA，怎么玩RPC，怎么玩dubbo。
web項目發(fā)展有幾個階段啊
之一個階段（單一應用架構）：
所有代碼都耦合在一個項目里，放在一臺服務器上，這種all in one的方式是有好處的。
創(chuàng)業(yè)初期，不用什么架構，走敏捷開發(fā)，最快速的實現(xiàn)需求才是王道。
你甭管我有多爛，我至少能跑起來，我至少能在外網上讓你訪問，讓你使用。
當然了，初期的訪問量很少，節(jié)省部署和運維成本才是王道呀。
聽阿里的講座，說淘寶的前期的版本用的就是一臺PC機作為服務器，所有的功能耦合在一個項目里，
每次往生產環(huán)境上發(fā)版本，要上傳一個600mb的包，呵呵。
第二個階段（垂直應用架構）：
哎喲，不錯哦。自己的兒子被越來越多的人訪問，訪問量激增，一臺服務器扛不住了，
沒事，我們可以玩負載均衡，玩集群。
但是！這種性能加速度其實會變得越來越小，因為你的項目是耦合在一起的。
這時，我們需要拆敗亮分項目，這里又有2個維度，按層拆，按模塊拆。
將拆好的不同項目分別部署在不同的服務器上，并且再分不同的小集群。
第三個階段（分布式服務架構）：
唉呀媽呀，訪問量陡增，到這步你創(chuàng)業(yè)應該算成功了，開始燒投資人的錢了吧。
經過上面拆成了越來越多的模塊，模塊與模塊交互越來越多，怎么辦？
這個時候我們需要把核心的業(yè)務抽出來，作為獨立的服務，慢慢發(fā)展成穩(wěn)定的服務中心，
用來提升業(yè)務復用和整合。
就像阿里的大牛說過，沒有淘寶的積累，天貓能那么快的出來嗎？
這個時候，你的緩存，數(shù)據庫，消息隊列等服務都應該是分布式的。
第四個階段（流動計算架構）
哎呀媽呀，訪問量又上了一個臺階，翻了好幾百倍吖，腫么辦？
這個時候服務越來越多，一些容量和資源的浪費問題凸顯出來，
這時我們需要一個調度中心來基于訪問壓力動態(tài)的管理集群容量，
提高利用率。
第五頃慶個階段（云計算架構）
抱歉，作者正在學習分布式架構中，未完待續(xù)。
首先我們先知道spring的項目分層：
按照MVC的設計理念來講，由service服務層調用持久層dao，在由controller調用service，這符合MVC的分層結構也坦正符合我們的編程習慣。
dao一般是做封裝，service做業(yè)務，controller校驗數(shù)據
要是controller直接調用dao的話，controller直接拿到數(shù)據這是游信模不安全的，而且平常的一些業(yè)務邏輯處理不好處理，因為業(yè)務需求是實時改變的，把業(yè)務寫在dao里還要全部更改業(yè)務信息，這樣不僅不會節(jié)約成本還增加耦合，代碼復用性也不高后期代碼維護也困難。建議還是遵循MVC分層結構神緩開發(fā)，盡管是少量數(shù)據也不建議直接調用dao。關于好處可以上別人博客借閱：
網頁鏈接
在controller調dao其實也沒問題,你還是沒搞明白為什么要分層,在規(guī)范上來說,dao層只處理與數(shù)據庫的交互,說白了就是怎么訪問數(shù)據信殲庫,比如查詢返回list,map.update,delete之類的,總體來說dao層幾乎都是固定化的東西,整個框架可以只用一個dao接口和實現(xiàn)類(前提是你知道泛型),整個service層都調用同一個dao,因為訪問數(shù)據庫就那么幾個需求.
service層又叫做業(yè)務層,本來組織sql之類的都是在這層寫,但是很多人會寫在dao層,其實是不對的,但是也沒人會在意,而且直接寫在dao層會看起來簡單,實則從長久看會麻煩,但是誰會在意呢,這只是個注重效率的時代,service層的目的是重用,就比如你要分頁查詢,就會分為3個方法,查list,查數(shù)量,和一個把這兩個組裝的方法,這樣分頁的時候直接調用組裝這個方法就可以了,其他地方要查list或者數(shù)量就可以調另外的方法,要是把這個都現(xiàn)在一個dao中那就只專用于查詢這個分頁了,所以從長久來說孫拍在service層寫sql是很有必要的(但是時間有時候不能讓你思考那么多),再有一個就是service是受數(shù)據庫事務控制的,就比如你一個請求要改變兩個表的數(shù)據,那在service層調用兩次dao就可以了,如果在controller調用兩次service那之一次成功第二次失敗了是不是還要回滾之一次的改變?
controller 主要是處理一些不想關業(yè)務的邏輯,就比如你人員表中存的人員所屬部門的id,你現(xiàn)在不可能把id直接顯示到頁面上,但是又想少些sql和少的代碼,那你就可以差分頁之后,再在controller中調用查部門的service,這樣把分頁查到的list遍歷一下就可以把按id把部門去,這樣的好處是你則坦羨人員的查詢service中的sql只關心人員表的數(shù)據,不用各種關聯(lián)其它表(但是有時候還是需要關聯(lián)的).
就說這么多吧,純手打,之一次打這么多東西….
Controller層：負責具體業(yè)搏塌務模塊流程的控制，即調用Service層的接口來控制業(yè)務流程。負責url映射（action）。
Dao層：負責數(shù)據持久化，與數(shù)據庫進行聯(lián)絡的任務都封裝在其中，Dao層的數(shù)據源以及相關的數(shù)據庫連接參數(shù)都在Spring配置文件中進行配置。Dao接口中的方法都大同小異，因為對數(shù)據庫的基本操作類似：insert、delete、update，select。 在Dao層定義的一些方法，在Service層并沒有被使用的情況：Dao層的操作經過抽象后基本都是通用的，在Dao層完成相關方法的定義，有利于支持后期Service層的擴展。（與相應的mapper對應）
Entity層：java對象，與數(shù)據庫表一一對應，是其對應的實現(xiàn)類。即一個Entity就是對應表中的一條記錄。
Service層：建立在DAO層之上，Controller層之下。調用Dao層的接口，為Controller層提供接口。負責業(yè)務模塊的邏輯應用設計，首先設計接口，再設計其實現(xiàn)的類。
View層：表示層，負責前端jsp頁面表示。
原因:
面向接口編程。表示層調用控配唯制層，控制基賣圓層調用業(yè)務層，業(yè)務層調用數(shù)據訪問層。
Dao層設計與設計的數(shù)據庫表，和實現(xiàn)類（對應的Entity或者JavaBean）一一對應。
View層與Controller層結合緊密，需要二者結合協(xié)同開發(fā)。Service層、Dao層和其他層次耦合很低，完全可以單獨開發(fā)。
spring mvc 里面的 mvc 是有其意義的。
mvc全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫。是一種軟件設計典范，用一種業(yè)務邏輯、數(shù)據、界面顯示分離的方法組織代碼，將業(yè)務邏輯聚集到一個部件里面，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業(yè)務邏輯。MVC被獨特的發(fā)展起來用于映射傳統(tǒng)的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。
可能你注意到了，這里面并沒有service，因為mvc概念也是從桌面軟件開發(fā)中移植過來的，所以在應用到網絡應用開發(fā)中，進行了一些改變，service層就是新演變出來的， service負責業(yè)務邏輯處理，如果滾碰慎沒有service層，那要把業(yè)務代碼放到controller中吵正，一些公共的方法就無法實現(xiàn)共享，總的來說，service的出現(xiàn)就是為了代碼重大敬用。
至于dao是屬于模型層的，也是一樣受用于分層的概念，分層的優(yōu)勢有兩個：解耦代碼、實現(xiàn)重用。
MVC只是一種設計規(guī)范，不是硬性的，比如：如果項目很小，那可以沒有service。
關于數(shù)據庫dao持久層設計的介紹到此就結束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關注本站。
成都創(chuàng)新互聯(lián)科技有限公司，經過多年的不懈努力，公司現(xiàn)已經成為一家專業(yè)從事IT產品開發(fā)和營銷公司。廣泛應用于計算機網絡、設計、SEO優(yōu)化、關鍵詞排名等多種行業(yè)！
新聞標題：深入探討數(shù)據庫DAO持久層的設計原理與實現(xiàn)(數(shù)據庫dao持久層設計)
URL鏈接：http://m.fisionsoft.com.cn/article/dhsehgg.html
