dao設計模式
① 什麼是DAO設計模式
DAO設計模式學習沖刺（8個月） 2009-04-07 18:04 閱讀88 評論0 字型大小： 大大 中中 小小 DAO設計模式 DAO(Data Access Object)模式實際上是兩個模式的組合，即Data Accessor 模式和 Active Domain Object 模式，其中 Data Accessor 模式實現了數據訪問和業務邏輯的分離，而Active Domain Object 模式，其中Data Accessor模式實現了數據訪問和業務邏輯的分離，而Active Domain Object 模式實現了業務數據的對象化封裝，一般我們將這兩個模式組合使用，因此，考慮到這些因素，這里將其作為同一個主題加以討論。如圖展示了DAO模式的實現層次。
DAO模式通過對業務層提供數據抽象層介面，實現了以下目標：
1. 數據存儲邏輯的分離
通過對數據訪問邏輯進行抽象，為上層機構提供抽象化的數據訪問介面。業務層無需關心具體的select,insert,update操作，這樣，一方面避免了業務代碼中混雜JDBC調用語句，使得業務落實實現更加清晰，另一方面，由於數據訪問幾口語數據訪問實現分離，也使得開發人員的專業劃分成為可能。某些精通資料庫操作技術的開發人員可以根據介面提供資料庫訪問的最優化實現，而精通業務的開發人員則可以拋開數據曾德繁瑣細節，專注於業務邏輯編碼。
2. 數據訪問底層實現的分離
DAO模式通過將數據訪問計劃分為抽象曾和實現曾，從而分離了數據使用和數據訪問的地稱實現細節。這意味著業務層與數據訪問的底層細節無關，也就是說，我們可以在保持上層機構不變得情況下，通過切換底層實現來修改數據訪問的具體機制，常見的一個例子就是，我們可以通過僅僅替換數據訪問曾實現，將我們的系統部署在不同的資料庫平台之上。
3. 資源管理和調度的分離
在資料庫操作中，資源的管理和調度是一個非常值得關注的主題。大多數系統的性能瓶頸往往並非集中於業務邏輯處理本身。在系統涉及的各種資源調度過程中，往往存在著最大的性能黑洞，而資料庫作為業務系統中最重要的系統資源，自然也成為關注的焦點。DAO模式將數據訪問邏輯從業務邏輯中脫離開來，使得在數據訪問層實現統一的資源調度成為可能，通過資料庫連接池以及各種緩存機制(Statement Cache,Data Cache等，緩存的使用是高性能系統實現的一個關鍵所在)的配合使用，往往可以保持上層系統不變的情況下，大幅度提升系統性能。
4．數據抽象
在直接基於JDBC調用的代碼中，程序員面對的數據往往是原始的RecordSet數據集，誠然這樣的數據集可以提供足夠的信息，但對於業務邏輯開發過程而言，如此瑣碎和缺乏寓意的欄位型數據實在令人厭倦。
DAO 模式通過對底層數據的封裝，為業務曾提供一個面向對象的介面，使得業務邏輯開發員可以面向業務中的實體進行編碼。通過引入DAO模式，業務邏輯更加清晰，且富於形象性和描述性，這將為日後的維護帶來極大的便利。試想，在業務曾通過Customer.getName方法獲得客戶姓名，相對於直接通過SQL語句訪問資料庫表並從ResultSet中獲得某個字元型欄位而言，哪種方式更加易於業務邏輯的形象化和簡潔化？
空洞地談些理論固然沒有什麼價值，我們需要看到的是通過對應用設計模式之後，我們的代碼到底有怎樣的改觀，進而才能對設計帶來的優劣有所感悟。下面讓我們來看看代碼：
[code]Public BigDecimal calcAmount(String customerID,BigDecimal amount){ //根據客戶ID獲得客戶記錄 Customer customer = CustomerDAO.getCustomer(customerID); //根據客戶登記獲得打折規則 Promotion promotion = PromotionDAO.getPromotion(customer.getLevel()); //累積客戶總消費額，並保存累計結果 Customer.setSumAmount(customer.getSumAmount().add(amount)); CustomerDAO.save(customer); //返回打折後金額 Return amount.multiply(promotion.getRatio()); }[/code]這樣的代碼相信已經足夠明晰，即使對於缺乏資料庫技術基礎的讀者也可以輕松閱讀。
從上面這段代碼中，我們可以看到，通過DAO模式對各個資料庫對象進行封裝，我們對業務層屏蔽了資料庫訪問的底層實現，業務曾僅包含與本領域相關的邏輯對象和演算法，這樣對於業務邏輯開發人員(以及日後專注於業務邏輯的代碼閱讀者)而言，面對的是一個簡潔明快的邏輯實現結構。業務層的開發和維護將變得更加簡單。
DAO模式中，資料庫訪問層實現被隱藏到Data Accessor中，前面說過，DAO模式實際上是兩個模式的組合，即Data Accessor 和 Domain Object模式。
何謂 Data Accessor?即將數據訪問的實現機制加以封裝，與數據的使用代碼相分離，從外部來看，Data Accessor 提供了黑盒式的數據存取介面。
Domain Object則提供了對所面向領域內對象的封裝。
從某種意義上，我們可以這么理解：
[code]Data Accessor object (DAO) =Data +Accessor + domain object[/code]
這個等式自左向右，形象地描述了設計分離的3個層次。
現在，對於上面的例子，來看看業務層後所隱藏的實現細節：
首先，我們這個計算打折後金額的業務過程中，涉及了兩個業務對象，即客戶對象Customer，和促銷規則對象Promotion。自然，這兩個對象也就成為了此業務領域(Business Domain)中的Domain Object，所謂Domain Object，簡單來講就是對領域內(Domain)涉及的各個數據對象，反映到代碼，就是一個擁有相關屬性的getter,setter方法的JavaClass(Java Bean)
以Customer和CustomerDao為例，實現代碼如下(Promotion 和 PromotionDAO的實現代碼與此類似)：
DAO 模式的進一步改良
上面的例子中我們通過DAO模式實現了業務路基與數據邏輯的分離。對於專項開發(為特定客戶環境指定的特定業務系統)而言，這樣的分離設計差不多已經可以實現開發過程中業務層面與數據層面的相對獨立，並且在實現復雜性與結構清晰性上達到較好的平衡。
然而，對於一個產品化的業務系統而言，目前的設計卻仍稍顯不足。相對專項原發的軟體項目而言，軟體產品往往需要在不同客戶環境下及時部署。一個典型情況就是常見的論壇系統，一個商業論壇系統可能會部署在廠前上萬個不同的客戶環境中。誠然，由於java良好的跨平台支持，我們在操作系統之間大可輕易遷移，但在另外一個層面，資料庫層，卻仍然面臨著平台遷移的窘境。客戶可能已經購買了Oracle,SQLServer,Sybase 或者其他類型的 資料庫。這就意味著我們的產品必須能部署在這些平台上，才能滿足客戶的需求。
對於我們現有的設計而言，為了滿足不同客戶的需求，我們可以實現針對不同類型資料庫的
Data Accessor,並根據客戶實際部署環境，通過類文件的靜態替換來實現。顯然，這樣的實現方式在面對大量客戶和復雜的部署環境時，將大大增加部署和維護工作的難度和復雜性。回憶一下「開閉原則」(Open-Close Principle) –對擴展開放，對修改封閉。我們應該採取適當的設計，將此類因素帶來的變動(類的靜態替換)屏蔽在系統之外。
為了實現跨資料庫平台移植，或者展開來說，為了支持不同數據訪問機制之間的可配置切換，我們需要在目前的DAO層引入Factory模式和Proxy模式。
這里所謂的不同數據訪問機制，包括了不同資料庫本身的訪問實現，同時也包括了對於同一資料庫德不同訪問機制的兼容。例如我們的系統部署在小客戶環境中，可能採用了基於JDBC的實現，而在企業環境中部署時，可能採用CMP作為數據訪問的底層實現，以獲得伺服器集群上的性能優勢(CMP具體怎樣還有待商榷，這里暫且將其作為一個理由)。
Factory模式的引入
由於需要針對不同的資料庫訪問機制分別提供各自版本的Data Accessor實現，自然我們會想通過 Java Interface 定義一個調用介面，然後對這個調用介面實現不同資料庫的 Data Accessor。通過以介面作為調用界面和實現規范，我們就可以避免代碼只能給對具體實現的依賴。
對於例子中的CustomerDAO而言，我們可以抽象出如下的介面：
[code]Public interface CustomerDAO{ Public Customer getCustomer(String custID); Puboic void save (Customer customer); }[/code]
這里作為示例，提供了兩個實現，一個基於MySql資料庫，一個基於Oracle，對這里的簡單示例而言，基於Oracle和MySql的實現並沒有什麼太大區別，只是為了說明系統設計的結構。
作為最常用的創建模式，Factory模式在這里起到來接介面和實現的橋梁作用。通過Factory模式，我們可以根據具體需要載入相應得實現，並將此實現作為所對應介面的一個實例提供給業務層使用：
[code]CustomerDAO custDAO =(CustomerDAO)DAOFactory.getDAO(CustomerDAO.class); Customer customer = custDAO.getCustomer(customerID);[/code]
通過上面的代碼我們可以看到，通過介面我們將具體的DAO實現從代碼中分離。
也就是說，業務層通過介面調用底層實現，具體的DAO實現類不會出現在我們的業務代碼中。而具體實現類在配置文件中加以配置，之後DAOFactory.getDAO方法通過讀取配置文件獲得當前我們期望使用的視線類的類名，再通過Java Class動態載入機制載入後返回。
從而我們的代碼並不依賴於某個特定的實現類，只需要在部署的時候在配置文件中指定當前採用的實現類即可。
本例中，為了提高性能，避免每次調用都讀取配置文件所引起的大量磁碟操作，採用了HashMap作為DAO緩存實現示例：
[code]package net.wanjin.lab.persistence.; import java.util.HashMap; public class DAOFactory { private static HashMap Map = null; /** * Return a implemetation instance of the specified DAO Interface * @return the DAO Implemmenation Class Instance */ public static Object getDAO(Class Interface){ initial(); Object = Map.get(Interface); if(null ==){ throw new DAOException("No Implementation found of DAO interface =>" +Interface.getName()); } return ; } /** * Initial the DAOFactory * Load DAO Interface and Implementation In Map for later use */ public static synchronized void initial(){ if(null==Map){ Map =DAOConfig.load();//根據配置文件載入DAO實現配置 } } }[/code]
[code]package net.wanjin.lab.persistence.; import java.util.Enumeration; import java.util.HashMap; import java.util.Properties; import org.apache.log4j.LogManager; import org.apache.log4j.Logger; /** * DAOConfig 類實現了配置文件的讀取功能，並根據配置文件中的內容載入制定的介面和實現類； * @author Administrator */ public class DAOConfig { private static Logger logger = LogManager.getLogger(DAOConfig.class); private static final String DAO_CONFIG_FILE=".xml"; private static final String DAO_CONFIG_SECTION="DAO"; /** * Load the DAO Interface_Implementation into a HashMap * @return */ public static synchronized HashMap load(){ HashMap map = new HashMap(); JFigLocator jfigLocator = new JFigLocator(DAO_CONFIG_FILE); JFigIF Config = JFig.getInstance(jfigLocator); Properties prop = Config.getSectionAsProperties(DAO_CONFIG_SECTION); Enumeration enumSection = prop.keys(); while(enumSection.hasMoreElements()){ String Iface =(String)enumSection.nextElement(); String Impl = prop.getProperty(Iface); try{ Class iface = ClassToolKit.loadClass(Iface); Class impl = ClassToolKit.loadClass(Impl); //將介面作為HashMap索引，實現類作為值 map.put(iface, impl); }catch(ClassNotFoundException e){ logger.debug("No Class Found"+e); } }//while enumSection return map; } }[/code[code]]//.xml 文件 <?xml version="1.0" encoding="UTF-8"?> <configuration> <section > <entry key="net.wanjin.lab.persistence..iface.CustomerDAO" value="net.wanjin.lab.persistence..impl.CustomerDAOImp_Mysql"/> <entry key="net.wanjin.lab.persistence..iface.PromotionDAO" value="net.wanjin.lab.persistence..impl.PromotionDAOImp_Mysql"/> </section> </configuration>[/code]
② 在DAO中如何體現DAO設計模式
把對象的基本CRUD操作封裝到一個DAO中就是這種設計模式
③ 使用DAO的設計模式，在介面中使用的是request.setAttribute
你是重定向到這個jsp頁面的吧 比如response.sendRedirect("XXX.jsp")，重定向之後的request不是之前的那個request了
所以裡面就沒數回據了，答可以用forward 不用redirect ,實在不行可以放到application里,在整個應用的生命周期中都可以找到。
④ java中DAO的設計模式的實現要求
一定要與其他各層解耦，可以使用代理模式，若上層有多個不同的類調用DAO層多個不同的對象的話，可以考慮使用中介者模式，不然的話調用關系太復雜會使得代碼維護非常麻煩
⑤ 設計模式中vo、pojo這些對象如何使用，以及他們的作用和有哪些好處，希望大家給給講解講解。
vo,pojo可以叫做值對象，顧名思義就是用來傳值的對象。比如，我有一個方法要求你版輸入3個參數，然權後返回一個結果。那麼我就可以把這個方法設置為a(Vo vo),vo是個類。那麼我就可以定義vo為
class VO{
private a;
private b;
private c;
public void getA(){
return a;
}
...
}
省略set和get方法。這樣的話，實例化一個vo類，就可以用set和get的方法定義或者取值，然後在調用方法的使用傳入這個實例。java強調萬物皆對象，這樣傳值是不是要比直接寫參數感覺要好的多呢
⑥ java中泛型的設計模式有哪些優點
把具體的實體交給子類
規定了特定的實體, 但沒有指定是誰。
只處理與資料庫相關的操作
未業務層提供介面
⑦ java設計模式中既然有層為什麼還要service層區別是什麼
層是和資料庫打交道的 邏輯層 裡面封裝了資料庫操作的一些基本方法。。
service層是業務內層 很可能你在注冊一個容用戶的時候還需要往日誌表裡加一個日誌，那麼就在service對這個業務實現 並對這個業務加上事務。。好處不言而喻了。。如果你在你的C層 連續用UserDao LogDao 那萬一某一步出錯了。有可能造成User加進去 Log沒加進去。
⑧ J2EE中的DAO是一種設計模式還是框架
其實設計模式談不上，同時也不是那種技術框架。
他是軟體開發架版構中的一個層次，權也就是數據訪問層。
DAO層負責訪問和操作資料庫。
傳授你一些開發經驗，DAO的顆粒度究竟要多細，就是精確到表，就是說常規的做法就是一個DAO類對應一張表，裡麵包含一些增刪改查的方法，每個方法只有一種行為，比如你不能在一個方法中寫一個查詢行為的同時又寫了一個刪除行為，這是DAO的開發大忌。
然後在Service或Manage層（也叫業務層或應用層）去組合調用Dao層中的方法。這個層負責事務和業務組合。
⑨ 「項目採用基於DAO的MVC設計模式實現」這句話是什麼意思
jsp DAO就是資料庫介面的意思 MVC自然就是3層架構，合起來自然就是用MVC設計模式實現帶有資料庫訪問功能的項目。軟體自然是MyEclipse，如要連接Mysql 還需要下載sql連接包
⑩ 求教java高手：什麼是DAO設計模式，聽老師說DAO設計模式通常會和工廠設計模式、代理設計模式一起使用，
class User {
private String name;
private int age;
public void setName(String name){
this.name=name;
}
public void setAge(int age){
this.age=age;
}
public String getName(){
return this.name;
}
public int getAge(){
return this.age;
}
}
interface UserDAO {
public boolean doCreate(User user)throws Exception;
}
class UserDAOImpl implements UserDAO {
private String str=null;
public UserDAOImpl(String str){
this.str=str;
}
public boolean doCreate(User user)throws Exception{
boolean flag=false;
try{
System.out.println("真實主題類的資料庫增加操作");
}catch(Exception e){
e.printStackTrace();
}finally{
}
return flag;
}
}
class UserDAOProxy implements UserDAO {
private UserDAOImpl =null;
private String str=null; //此處其實應該傳入一個資料庫的連接到真實主題類的，不過這里只是個演示，所有以字元串的形式傳了進去
public UserDAOProxy(){
this.str=new String();
this.=new UserDAOImpl(this.str);
}
public boolean doCreate(User user)throws Exception{
boolean flag=true;
System.out.println("代理類的操作，打開資料庫，同時取得真實主題類的實例去調用真實的數據層操作");
try{
this..doCreate(user);
}catch(Exception e){
e.printStackTrace();
}finally{
System.out.println("代理類的操作，調用完真實主題類的操作，同時關閉資料庫");
}
return flag;
}
}
class UserDAOFactory {
public static UserDAO getUserDAONewInstance(){
System.out.println("通過工廠類取得代理類的實例去調用代理類的操作。");
return new UserDAOProxy();
}
}
public class FactoryDemo {
public static void main(String args[])throws Exception{
User user=new User();
user.setName("jhjjs");
user.setAge(20);
UserDAOFactory.getUserDAONewInstance().doCreate(user);
}
}
lz看下吧，剛做的