我的實體只有 setter 和 getter 但沒有方法 - 設計失敗 -

Question

我讀過一次：

“除非你有充分的理由，否則不要將實體作為一袋 getter 和 setter，並將它們的方法放在另一層中”

我的客戶、訂單、...對象只是從 SqlDataReaders 獲取數據。 他們只有 getter 和 setter。

我的第一個問題是，當有人在實體中實現方法時，這遵循哪種設計方法以及這些方法在做什么？

Answer 1

這種思維方式來自領域驅動設計社區。

在 DDD 中，您可以創建一個域模型來捕獲用戶請求的功能。 您將實體設計為具有功能和它們所需的數據。 您將它們組合在一起，並擁有負責構建（工廠）和查詢（存儲庫）的單獨類。

如果您只有 getter/setter，那么您就有一個“貧血領域模型”。 Martin Fowler 在這篇文章中寫到了它。

貧血域模型的問題在於您有將數據庫映射到對象的開銷，但沒有它的好處。 如果您不將實體用作真正的域模型，為什么不直接使用 DataTable 或其他數據來保存您的業務邏輯？ 貧血領域模型是一種應該避免的反模式。

您還提到您自己映射實體。 這篇博客解釋了為什么使用對象關系映射工具真的很有幫助。 如果您使用 Entity Framework 和 Code First 方法，您可以編寫一個包含數據和功能的干凈域模型，並將其映射到您的數據庫，而不會很麻煩。 然后，您將擁有兩全其美。

Answer 2

當您將方法作為模型的一部分時，您應該只包含模型特定類型的邏輯。 例如，考慮一個銀行賬戶：

public class Account {
   public AccountId Id { get; set; }
   public Person Customer {get; set; }

   public void Credit(Money amount) { ... }
   public void Debit(Money amount) { ... } 

}

Credit 和 Debit 是特定於模型的邏輯（在應用程序的其他任何地方都找不到它們），應該封裝在 Account 類中。

您還提到您在模型類中使用了 SqlDataReader 從數據庫中獲取數據。 這是一個很大的反模式。 以下是您將遇到的一些問題：

1. 違反單一職責原則 - 該模型現在負責表示數據並從數據庫中獲取數據。
2. 在你的模型中查詢孩子怎么樣？ 它變得凌亂。
3. 您將無法輕松更改數據訪問權限。

保持模型精益。 將數據訪問邏輯放在一個存儲庫中，即AccountRepository。