將DAO注入構造函數被認爲是不好的做法嗎？如果是這樣，爲什麼？

我有一個（DAL）數據訪問層（但這個問題與DAO相關），它與Android中的一個寧靜的Web服務進行通信（除了我不想包含沉重的安寧作爲交互的圖書館並不那麼複雜）。將DAO注入構造函數被認爲是不好的做法嗎？如果是這樣，爲什麼？

我有一個對象，它包裝一個由此數據訪問層的信息填充的列表，當用戶掃描併到達此列表的底部時，此對象從DAL檢索另一組信息。

我想這個列表的調用類包裝對象只需要調用列表包裝對象而不是DAL（或DAO）。然後，我可以構造一個DAL並將其傳遞給這些列表包裝對象的構造函數，然後調用類可以繼續調用此列表包裝對象，並且該對象可以處理新信息的復原。

那麼，這聽起來像不好的做法或只是一個非常糟糕的解釋？

將DAL和DAO注入到域對象的構造函數中是不是一個好主意？

來源

2011-10-05 zode64

如果問題是針對Android的，將它作爲標籤是否合理？ –

想要它成爲一個更普遍的問題，但事後看來，android因素似乎比我原先想象的更相關。我已經添加了標籤。 – zode64

答案取決於你是否強烈地感受到「貧血域模型」和混合面向對象與函數式編程。

一個問題是您將以這種方式創建循環依賴關係：模型和持久性包必須相互瞭解。如果您使用更多功能的樣式，並且不給模型對象提供DAO引用，那麼它是單向關係。

我不太喜歡你的設計。我擔心它太耦合了。我並沒有將功能風格混入其中。

來源

2011-10-05 14:06:11 duffymo

如果數據訪問層的任務並不是實際構造域對象，而是隻爲相關信息提供相關信息（在本例中爲json字符串），以便構建列表對象，那麼我將刪除循環依賴關係（儘管我當時意識到它不再是DAL/DAO，而只是一個適配器）。你怎麼看？ – zode64

額外的併發症沒有任何好處，我可以看到。 – duffymo

Domain Objects通常是沒有任何實際邏輯的數據載體。因此，我會認爲這是一種糟糕的設計，將它與你的邏輯緊密結合在一起。一般邏輯可能是這樣的：

public class DataService { 
    private DAO dao; 
} 

public class UserService { 
    private DataService svc; 

    public DomainObject createDomainObject() { 
     return new DomainObject(dao.getData()); 
    } 
}

來源

2011-10-05 14:07:37

本聲明 - 「域對象通常是沒有任何實際邏輯的數據載體」，有點不正確。域對象意味着具有業務邏輯並且成爲富域模型的一部分，這不同於意味着作爲數據載體（並且在貧血域模型中發現）的DTO。 –

如果我正確理解你正在執行的是分頁。而你的解決方案就是我將如何（並且已經）自己實現它。

將DAL傳遞給構造函數本身並不壞。最佳實踐是使用Dependency Injection框架（Spring是一個突出的例子），以避免層之間的「硬編碼」依賴關係。

但是既然你提到了Android，我懷疑使用這樣的框架是一個好主意，甚至是可能的。（也許Android有某種類型的DI內置？）

總結一下，你似乎已經對你的應用程序體系結構進行了一些思考。我不擔心將參數傳遞給構造函數。

來源

2011-10-05 14:07:43 BernardMarx

你在那裏引入循環依賴，所以它不是最好的設計。

如果您正在開發Android應用程序，並且您正在滾動列表，那麼SlowAdapter和EfficientAdapter可能就是您要查找的內容。

來源

2011-10-05 14:08:23

如果數據訪問層的任務並不是實際構造域對象，而只是提供相關信息（在這種情況下爲json字符串）來構造列表對象，那麼我將刪除循環依賴項（儘管我當時意識到它不再是DAL/DAO，而只是一個適配器）。你怎麼看？ – zode64

將DAO注入構造函數被認爲是不好的做法嗎？如果是這樣，爲什麼？

回答

相關問題