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