我已经阅读了一些关于贫血域模型和关注点分离的问题。在贫血的域对象上执行/附加域逻辑的最佳技术是什么?在我的工作中,我们有一个非常贫乏的模型,我们目前正在使用“帮助器”类来在域对象上执行数据库/业务逻辑。例如:
public class Customer
{
public string Name {get;set;}
public string Address {get;set;}
}
public class Product
{
public string Name {get;set;}
public decimal Price {get;set;}
}
public class StoreHelper
{
public void PurchaseProduct(Customer c, Product p)
{
// Lookup Customer and Product in db
// Create records for purchase
// etc.
}
}
当应用程序需要进行购买时,它会创建 StoreHelper,并调用域对象上的方法。对我来说,客户/产品知道如何将自己保存到存储库是有意义的,但您可能不希望域对象上的 Save() 方法。对于像 Customer.Purchase(Product) 这样的方法也很有意义,但这会将域逻辑放在实体上。
以下是我遇到的一些技术,不确定哪些是好/坏:
- Customer 和 Product 继承自“Entity”类,该类以通用方式提供基本的 CRUD 操作(可能使用 ORM)。
- 优点:每个数据对象都会自动获取 CRUD 操作,但随后会绑定到数据库/ORM
- 缺点:这并没有解决对象上的业务操作问题,并且还将所有域对象绑定到可能不合适的基本实体
- 使用帮助类来处理 CRUD 操作和业务逻辑
- 将 DAO 用于“纯数据库”操作是否有意义,而将业务助手用于更特定于业务的操作是否有意义?
- 为此使用非静态或静态辅助类更好吗?
- 优点:领域对象不依赖于任何数据库/业务逻辑(完全贫乏)
- 缺点:不是很面向对象,在应用程序代码中使用助手不是很自然(看起来像 C 代码)
- 使用 Double Dispatch 技术,其中实体具有保存到任意存储库的方法
- 优点:更好的关注点分离
- 缺点:实体附加了一些额外的逻辑(尽管它是解耦的)
- 在 C# 3.0 中,您可以使用扩展方法将 CRUD/业务方法附加到域对象而不接触它
- 这是一种有效的方法吗?什么是优点/缺点?
- 其他技术?
处理此问题的最佳技术是什么?我对 DDD 很陌生(我正在阅读 Evans 的书——所以也许这会让我大开眼界)