提供依賴給行爲實體

這是怎樣的一個普遍的問題，所以我會盡力來形容我的使用情況下，希望這將是很清楚提供依賴給行爲實體

我已經創建了一組實體建模我域。每個實體都有自己的屬性來描述它的屬性。

假設之一是用戶實體（我使用PHP的例子）

class User 
{ 
    private $email; 
    private $password; 
}

現在我想給我的實體一些更高級的行爲比起獲取和設置其屬性。

例如，假設我想創建這樣的方法

public function authenticate($email, $password)

要做到這一點，我想的方法來寫需要一些依賴。在這個例子中，這可能是一個AuthenticationService。

現在，我的問題是，哪一個是將這些依賴項傳遞給我的方法的最佳實踐？

某些選項可能是：

1）不要傳遞依賴關係。將所有實體行爲放在其他服務中。

2）將構造函數中的依賴關係傳遞給我的實體。如果是這樣，我的問題是：一個實體依賴於外部服務是否正確？

class User 
{ 
    private $authenticationService 

    public __construct($authenticationService) 
    { 
     $this->authenticationService = $authenticationService; 
    } 
}

3）傳遞的依賴關係爲我的方法調用

public function authenticate($email, $password, $authenticationService)

這是最好的解決辦法的論據？除了上面列出的選項之外是否還有其他選項？

來源

2015-06-19 marcosh

那麼，這是一個關於Martin Fowler稱之爲anemic domain model anti-pattern的非常古老的討論。

雖然我絕不認爲我比這個偉大的馬丁福勒更有資格談論這個問題，但我幾乎同意這個關於貧血域模型的article更尊重SOLID的設計原則。

所以，IHMO，如果User是一個實體，所以它應該是這樣的一個POPO（普通老式PHP對象），或者可能具有一些固有的邏輯本身，例如像：

class User { 
    //... 
    public function isAdmin() { 
     return $this->role == self::ROLE_ADMIN; 
    } 
    //... 
}

當你通過組合構建實體的對象部分，你可能違反了單一職責原則（SRP），並且肯定會打破關注分離原則（SoC）。

而且，你能想到是這樣的：

的User是一個實體，因爲它的存在本身，它不需要別的是一個用戶。而AuthenticationService是一項服務（duh！），將檢查用戶的優先。所以，這取決於用戶是有用的。

因此，User對象應該是AuthenticationService對象的參數，而不是其他方式。

來源

2015-06-19 18:45:48

提供依賴給行爲實體

回答

相關問題