c# – 域驱动设计的存储库模式是否成为反模式？

首先我想澄清一点,我是域驱动设计的新人物,而且我在问这个问题,因为我已经读过一些名为“无神域模型”的东西.

大多数时候,我在使用Repository模式时看到以下事情.

>我们有一个通用存储库
>我们有只包含一组公共属性的模型,但它不包含任何方法(所以根据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,所以我的问题是：我的产品类是一个贫血模型吗？

请考虑以下示例图像,我想说的话.

解决方法

我同意IRepository界面通常是浪费时间.如果我将基本的CRUD操作放在我的IRepository接口中,那么如何处理数据呢像审计数据呢？删除它将被禁止.当我尝试调用Delete()时,应该返回一个InvalidOperationException？

有些人提出了较小的界面,如可读,可写,可更新或IDeleteable.我认为这种做法甚至更加麻烦.

对于DDD,我喜欢使用每个存储库的接口(主要用于IoC和单元测试),而个人(这只是我自己的解决方案之后).这给了我IUserRepository,IAuditLogRepository等.我的存储库还采用(作为参数)并返回域实体(聚合根或单个实体).这样一来,DTO对象就不会维持或混乱我的解决方案.然而,我仍然使用视图模型来保护敏感数据不受我的观点影响.

有很多参数在线和反对存储库模式.

c# – 域驱动设计的存储库模式是否成为反模式？

解决方法

相关文章