DDD 和存储库模式将有关 CRUD 的行为放在哪里答案

【问题标题】：DDD and Repository pattern where to put behavior concerning CRUDDDD 和存储库模式将有关 CRUD 的行为放在哪里
【发布时间】：2012-03-09 14:19:29
【问题描述】：

我尝试将尽可能多的业务逻辑放在我的领域模型中。

每次更新 MyEntity 时，我都希望发生两件事：

向创建它的用户发送消息
检查更改是否适用于某些业务规则

如果实体不是聚合根的子级。

通常我会从存储库中获取特定实体。更改实体，并将其持久化
使用 MyRepository.Save() 回到数据库

在这种情况下，我必须将业务逻辑放在我的应用程序或 DAL 中，而不是域模型中。我试图避免使用业务逻辑层，除非绝对必要，但我似乎无法适应这一点，除非我创建一个名为 MyEntity.Update() 或类似的方法，但我有一种不正确的感觉方法来做到这一点。

【问题讨论】：

您确定这些操作属于应用程序特定域吗？
嗯，这个问题是一般性的，因为它不需要是这个特定的逻辑，而是当您更改不是聚合根的实体时适用的任何逻辑或规则。

标签： c# repository domain-driven-design persistence

【解决方案1】：

首先让我声明，我并不反对存储库模式。我最近在一个项目中成功使用了一个。

我会说要小心...如果您不能将需求封装在您的对象中，您的 OO 方法可能需要重新审视。为了做其他事情而引入数据访问层似乎是一种代码味道。我使用服务层来接收请求并管理事务和版本控制，但不是用于验证等其他事情。您的服务层可能如下所示。

    public enum UpdateResult
    {
         Success,
         NoMyEntityFound,
         StaleData,
         InvalidRequest
    }


public class MyService
{


     ...
     ...


     public UpdateResult Update(...)
     {
          ...Start Tran
          ...Load var m = MyEntity
          ...do the bare minimum here 
          ...m.Update()
          ...Commit Tran

          return UpdateResult.Success;
     }

}

说了这么多关于存储库的警告

http://ayende.com/blog/3955/repository-is-the-new-singleton

【讨论】：

好的，谢谢你的例子。您会将其实现为域服务吗？