14

首先，我想澄清一下我是域驱动设计的新手，我之所以问这个问题是因为我读过一些叫做贫血域模型的东西。

大多数时候，我在使用存储库模式时会看到以下内容。

  1. 我们有一个通用存储库
  2. 我们的模型只包含一组公共属性，但它不包含任何方法（因此根据 DDD 的定义它成为贫血域模型），因为这里存储库类处理该实体或模型的其他进程。

请为我的查询提供您宝贵的答案。

让我澄清几件事。

通用存储库是指由实体存储库实现的通用接口。

我的困惑是关于以下事情

例如：假设我想保存

    public class User
    {
        public int Id { get; set;}
        public string Name { get; set};
    }

    public class UserRepository : IRepository<User>  
    {  
        // All Operation Like Save / Get /  UserEntity (Domain Object)       
    }

所以这是我的 User 类什么都不做，而是它只有属性和其他操作句柄UserRespository。所以我的用户是贫血域模型。（因为它没有做任何具体的事情）

在附图中，我认为ProductRepository我的问题是：我的产品类是贫血模型吗？

请考虑按照我想说的示例图片。

在此处输入图像描述

4

2 回答 2

23

我同意IRepository界面通常是浪费时间。如果我把基本的 CRUD 操作放在我的IRepository界面中，那么我该如何处理审计数据之类的数据呢？在哪里删除它是被禁止的。InvalidOperationException当我尝试打电话时，我应该只返回 aDelete()吗？

有些人建议使用更小的接口，如IReadable,或. 我认为这种方法更加混乱。IWriteableIUpdateableIDeleteable

就个人而言（这只是我自己的解决方案，在对其他所有内容进行了很好的运行之后），对于 DDD，我更喜欢为每个存储库使用一个接口（主要用于 IoC 和单元测试）。这给了我IUserRepository,IAuditLogRepository等。我的存储库也接受（作为参数）并返回域实体（聚合根或单个实体）。这样就没有贫血的 DTO 对象来维护或弄乱我的解决方案。但是，我仍然使用视图模型将敏感数据排除在我的视图之外。

网上有很多支持和反对存储库模式的论据。

于 2013-08-07T08:29:06.767 回答
22

存储库模式本身并不是一种反模式，但我已经看到了许多 DDD 实现，其中存储库模式提供的价值很少或没有。将你的 n-tier-provide-no-value 分层架构交给务实的铁杆专家开发人员，他可能会给你“反模式”的批评（我可能会说是有效的）。

存储库模式优点：

  1. 底层持久化技术的抽象
  2. 定义聚合根的可能性，只有聚合根应该有存储库
  3. 一种明确说明哪些操作对所讨论的聚合根有效的方法，例如，如果删除您的实体无效，则您的存储库应该没有删除方法。
  4. 无需数据库即可轻松测试的东西（存根存储库）

存储库模式缺点：

  1. 贴近您的持久性技术。
  2. 又一个层次

我个人更喜欢在做 DDD 时使用存储库模式，但是您的解决方案听起来更像是活动记录模式，因此首先消除了使用存储库的大部分好处。我从不做通用存储库，因为它们删除了优点 2 和 3（我可以有一个通用的实现，但我不会将它直接暴露给存储库消费者代码）。

另外：不要使用存储库来填充 DTO、ViewModel 等。使用单独的模型和技术来建模写入（DDD 可以很好地工作）和读取。

于 2013-08-07T07:00:29.117 回答