服務和DAO設計模式

我對代理服務和DAO設計模式有疑問。我們的團隊認爲我們將爲DAOFactory和DAO對象使用Singleton模式。 DAOFactory將包含所有可用的DAO作爲其屬性，並在需要時提供它們。服務和DAO設計模式

現在我們對服務是否說例如AuthenticateSerivce應包含所有必需的DAO，例如， UserDAO，RoleDAO等屬性？或者它應該調用get ** DAO（）每當其需求的基礎上需要，而不是設置爲自己的特性（附件是Java文件）

代碼片段：

public class AuthenticateService { 
    UserDao userDao; 
    RoleDao roleDao; 

    public AuthenticateService(){ 
     DaoFactory daoFactory = DaoFactory.getInstance(); 
     userDao = daoFactory.getUserDao(); 
     roleDao = daoFactory.getRoleDao(); 
    } 


} 


public class DaoFactory { 

    private static DaoFactory instance = null; 

    UserDao userDao; 
    RoleDao roleDao; 
    AnnualScheduleDao annualScheduleDao; 
    WeeklyScheduleDao weeklyScheduleDao; 
    ProgramSlotDao programSlotDao; 

    private DaoFactory(){ 
     // Authenticate 
     userDao = new UserDaoImpl(); 
     roleDao = new RoleDaoImpl(); 

     // Schedule 
     annualScheduleDao = new AnnualScheduleDaoImpl(); 
     weeklyScheduleDao = new WeeklyScheduleDaoImpl(); 
     programSlotDao = new ProgramSlotDaoImpl(); 

    } 


}

哪種方法更好，在哪些情況？

來源

2012-08-26 Atul

我認爲第一個更好（即屬性），因爲它更容易管理它們。代碼也會更清潔，而不是以不同的方法調用Factory，或者在每種方法中都有一個dao變量。您可以輕鬆修改Daos以便以後使用，而無需在幾個區域內進行替換。如果你決定在那裏初始化Dao，或者創建一個自定義的dao來使用，或者稍後使用依賴注入，那麼你不必重新訪問所有對DaoFactory的調用。

第二個問題是使用DAO的單例。我不確定每個DaoImpl是如何完成的，但是當服務被多個線程訪問時（有時候取決於你如何實現你的Daos）並且他們共享相同的Dao時，線程有問題。或者，也許你想使用一個Factory來爲每個請求實例化一個新的Dao？但是如果是這樣的話，那麼我相信你會選擇第一個選項，因爲你不想在每種方法中重新創建一個dao。（假設你的團隊擔心性能問題），所以他們不需要按需實例化，但你應該做一些連接或資源池（例如，重新使用Db連接）。

來源

2012-08-26 09:40:59

我同意你的觀點。但是，我認爲DAOFactory是所有DAO的容器，並且只要需要就將它們提供給Service（通過創建新的DAO或再次使用相同的n或通過池再次使用它），則不需要保留DAO as attirubte of Service。但現在，我會採用你建議的方法，因爲我沒有任何理由使用第二個;） – Atul

但是在使用DAOFactory的時候需要小心，它只返回一個相同的Dao，特別是如果它們是維護國家。這在多線程場景中肯定會遇到問題，您必須爲其他開發人員記錄此問題。另外，其他開發人員必須始終如一地使用工廠，或者向工廠添加新的Daos，除非您真的打算使用工廠，不同類型的UserDao「製造」，否則我認爲這是不必要的。 –

創建新的dao或通過在服務中的每個方法中調用每個調用似乎比在服務的構造函數中執行一次更昂貴。因爲用戶需要將dao關閉（）或返回（）到池中，所以Dao池似乎增添了麻煩。因爲close（）應該被調用，所以最好在Dao內部建立連接。 –

服務和DAO設計模式

回答

相關問題