將DAO注入構造函數是否被視為不良做法？ 如果是這樣，為什么？

Question

我有一個（DAL）數據訪問層（但是這個問題也與DAO有關），它正在與android中的一個寧靜的Web服務進行通信（除了我不想包含大量的寧靜的庫這一事實之外，它的相關性較小）互動並不是那么復雜）。

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

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

那么，這聽起來像是不好的做法還是只是一個很糟糕的解釋？

在域對象的構造函數中注入DAL和DAO是一個壞主意嗎？

Answer 1

答案取決於您是否對“貧血症領域模型”有強烈的興趣，以及是否將面向對象與函數式編程混合在一起。

一個問題是，您將以這種方式創建循環依賴關系：模型包和持久性包必須彼此了解。 如果您使用更具功能性的樣式，並且沒有給DAO引用模型對象，那么這是一種單向關系。

我不太喜歡您的設計。 我擔心它太耦合了。 我不喜歡混用功能樣式。

Answer 2

Domain Objects通常是沒有任何實際邏輯的數據載體。 因此，我認為將其與您的DAO邏輯緊密耦合是不好的設計。 一般邏輯可能類似於：

public class DataService {
    private DAO dao;
}

public class UserService {
    private DataService svc;

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

Answer 3

您將在此處引入循環依賴關系，因此它不是最佳設計。

如果您正在開發一個android應用程序，並且正在滾動列表，那么SlowAdapter和EfficientAdapter可能就是您想要的。

Answer 4

如果我對您的理解正確，那么您正在實現的就是分頁。 您對此的解決方案是我自己（並將自己）實現它的方式。

將DAL傳遞給構造函數本身並不壞。 最佳實踐是使用依賴性注入框架（Spring是一個突出的示例），以避免層之間的“硬編碼”依賴性。

但是自從您提到Android以來，我懷疑使用這樣的框架是個好主意，甚至可能。 （也許Android內置了某種DI？）

總而言之，您似乎已經考慮了您的應用程序體系結構。 我不用擔心將參數傳遞給構造函數。