(DDD)仓储的思考

(DDD)仓储的思考

为什么需要仓储呢?领域对象(一般是聚合根)的被创建出来后的到最后持久化到数据库都需要跟数据库打交道,这样我们就需要一个类似数据库访问层的东西来管理领域对象。那是不是我们就可以设计一个类似DAL层的东东来管理对象呢?是的,但是呢设计上有点区别,就是我们不希望上层如应用层直接访问数据,我们所有的操作应该是围绕着领域对象来的,所以我们还设计了仓储接口在领域层,然后把仓储的实现放在基础设施层。这样的设计模式很常见,一般用来解耦的。但是仓储不处理事务,事务处理我们一般交给UnitOfWork,有关于UnitOfWork的介绍大家可以参考下我之前一篇文章UnitOfWork以及其在ABP中的应用

ABP中设计仓储的思路,其实也很简单,就是提供领域对象的一些常用的数据库操作,一般的仓储存放的对象是聚合根,但是呢ABP没有严格区分聚合根,它简单的把所有的对象都当作聚合根,这样的设计也见于NOP中。下面我是画了ABP仓储设计的一张类图。

这个类图中我们可以清楚的看出几个:

1、仓储设计的意义,有人说我用EF开发DbSet<T>其实就是一个仓储的呀,我干嘛还需要重新定义一个Repository呢?答案在上图中体现的很明显,我们可能不确定以后我们的项目时候会用到其他数据库访问框架,比如NHibernate或MongoDb。那么如果我设计了IRepository这个接口后,我如果哪天我项目需要用到MongoDB了,那么我就可以继承IRepository实现一个MongoDbRepositoryBase类。

2、AbpRepositoryBase这个基类GetAll返回的是IQueryable<T>,但是呢IQueryable返回的是一个查询分析器,不是一个结果Model。这样我们就没办法确定这个GetAll到底是返回什么,就没有办法单元测试等。这个问题之前已经在蟋蟀博文Repository 返回 IQueryable?还是 IEnumerable?中讨论过了,有兴趣的同学可以参考下哈。一般的严格DDD是不能这个直接返回IQueryable的,但是如果你不是严格的DDD就无所谓了。为此我特地参考了下netfocus的ENode的案例forum,具体可以查看博文ENode简介与各种资源汇总(持续更新中。。。)下面我们来看下netfocus专家是怎么设计的吧。因为对forum还不是很熟悉,我只找到到账号索引仓储的设计。


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

namespace Forum.Domain.Accounts

{

    /// <summary>

    /// 账号索引信息的仓储接口,用于存储账号的唯一索引信息,实现账号名称的唯一性约束

    /// </summary>

    public interface IAccountIndexRepository

    {

        /// <summary>根据账号名称检索账号索引信息

        /// </summary>

        /// <param name="accountName"></param>

        /// <returns></returns>

        AccountIndex FindByAccountName(string accountName);

        /// <summary>添加一个账号索引

        /// </summary>

        /// <param name="index"></param>

        void Add(AccountIndex index);

    }

}

接下来是基础设施层的实现方法


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

namespace Forum.Domain.Dapper

{

    [Component]

    public class AccountIndexRepository : IAccountIndexRepository

    {

        public AccountIndex FindByAccountName(string accountName)

        {

            using (var connection = GetConnection())

            {

                connection.Open();

                var data = connection.QueryList(new { AccountName = accountName }, Constants.AccountIndexTable).SingleOrDefault();

                if (data != null)

                {

                    return new AccountIndex(data.AccountId as string, accountName);

                }

                return null;

            }

        }

        public void Add(AccountIndex index)

        {

            using (var connection = GetConnection())

            {

                connection.Open();

                connection.Insert(new

                {

                    AccountId = index.AccountId,

                    AccountName = index.AccountName

                }, Constants.AccountIndexTable);

            }

        }

        private SqlConnection GetConnection()

        {

            return new SqlConnection(ConfigSettings.ConnectionString);

        }

    }

}

从上面我们可以知道,它用的数据访问技术是Dapper,不是EF,它也没有IQueryable的设计,需要什么就查找什么比如FindByAccountName,这个就是严格按照DDD模式设计的仓储。这样的设计和ABP的设计各有优点,看项目需求吧。至此我的仓储也先总结到这里了,我还是DDD的初学者,可能有些理解不到位,希望相互学习共同成长。博客园已经有很多类似的文章了,这篇主要设计到ABP相关的,作为ABP的系列的一篇。

参考文章:

http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html

http://www.cnblogs.com/xishuai/p/repository-return-iqueryable-or-ienumerable.html

http://www.cnblogs.com/jesse2013/p/ddd-repository.html

时间: 2024-10-31 16:53:10

(DDD)仓储的思考的相关文章

关于领域驱动设计(DDD)仓储的思考

为什么需要仓储呢?领域对象(一般是聚合根)的被创建出来后的到最后持久化到数据库都需要跟数据库打交道,这样我们就需要一个类似数据库访问层的东西来管理领域对象.那是不是我们就可以设计一个类似DAL层的东东来管理对象呢?是的,但是呢设计上有点区别,就是我们不希望上层如应用层直接访问数据,我们所有的操作应该是围绕着领域对象来的,所以我们还设计了仓储接口在领域层,然后把仓储的实现放在基础设施层.这样的设计模式很常见,一般用来解耦的.但是仓储不处理事务,事务处理我们一般交给UnitOfWork,有关于Uni

Java架构:一文读懂微服务架构的重构策略

你很有可能正在处理大型复杂的单体应用程序,每天开发和部署应用程序的经历都很缓慢而且很痛苦.微服务看起来非常适合你的应用程序,但它也更像是一项遥不可及的必杀技.如何才能走上微服务架构的道路?下面将介绍一些策略,帮你摆脱单体地狱,而无须从头开始重写你的应用程序. 通过开发所谓的绞杀者应用程序(strangler application),可以逐步将单体架构转换为微服务架构.绞杀者应用程序的想法来自绞杀式藤蔓,这些藤蔓在雨林中生长,它们包围绕树木生成,甚至有时会杀死树木.绞杀者应用程序是一个由微服务组

DDD领域驱动设计仓储Repository

DDD领域驱动设计初探(二):仓储Repository(上) 前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇

C#进阶系列——DDD领域驱动设计初探(二):仓储Repository(上)

前言:上篇介绍了DDD设计Demo里面的聚合划分以及实体和聚合根的设计,这章继续来说说DDD里面最具争议的话题之一的仓储Repository,为什么Repository会有这么大的争议,博主认为主要原因无非以下两点:一是Repository的真实意图没有理解清楚,导致设计的紊乱,随着项目的横向和纵向扩展,到最后越来越难维护:二是赶时髦的为了“模式”而“模式”,仓储并非适用于所有项目,这就像没有任何一种架构能解决所有的设计难题一样.本篇通过这个设计的Demo来谈谈博主对仓储的理解,有不对的地方还望

DDD的思考

关于DDD的思考1.聚合根尽量要小,封装了聚合根内部的所有操作:外部必须通过聚合根才能访问聚会里面的内容:2.多个聚合根一起工作,需要通过领域服务或者事件来完成协调工作:3.Repository是聚合根的仓储,用于储存聚合根的数据:IRepository的定义放在领域Domain,Repository的实现放在基础设施层,这样就可以做到领域不依赖基础设施层,而仅仅依赖接口:4.一个聚合的新增: 1>.引用层通过领域仓储获取领域聚合根Gid,通过聚合根内部方法,完成内部操作,返回聚合根数据,应用层

关于DDD中Domain的思考

本文既不推销UML,也不推广DDD,更不涉及各种论战.-- 作者 某天又一次打开关于DDD(领域驱动设计)的PDF文档时,自己有了个疑问:什么是领域(Domain)?译文中是这样描述领域:银行业务被银行的内部人员和专家所熟知.他们知道所有的细节.所有的困难.所有可能 出现的问题.所有的业务规则.这些就是我们永远的起始点:领域.如果这就是领域,它似乎不是"起始点",而是"全部"--全部的业务规则.全部的细节.全部可能出现的问题.我的疑问正是始于此:Domain映射到软

从Entity Framework的实现方式来看DDD中的repository仓储模式运用

一:最普通的数据库操作 static void Main(string[] args) { using (SchoolDBEntities db = new SchoolDBEntities()) { db.Students.Add(new Student() { StudentName = "nihao" }); db.SaveChanges(); } } domain 和 db 是怎么操作... DbSet<Student> 集合 [用于存放集合] 从名称中可以看出,是

DDD实践问题之 - 关于论坛的帖子回复统计信息的更新的思考

之前,在用ENode开发forum案例时,遇到了关于如何实现论坛帖子的回复的统计信息如何更新的问题.后来找到了自己认为比较合理的解决方案,分享给大家.也希望能和大家交流,擦出更多的火花. 论坛核心领域问题分析 论坛领域的核心概念是:帖子.回复.大家都知道,一个帖子可以有零个或多个回复.对同一个帖子,不同的人可以并行发表回复.回复发表后,查看帖子详情时,可以根据回复的发表时间排序显示:此外,我们还关心某个帖子的最新发表的回复.最新回复的作者.最新回复时间,以及总回复数. 我们设计的系统,应该在实现

应用程序框架实战二十一:DDD分层架构之仓储(介绍篇)

前面已经介绍过Entity Framework的工作单元和映射层超类型的封装,从本文开始,将逐步介绍仓储以及对查询的扩展支持. 什么是仓储 仓储表示聚合的集合. 仓储所表现出来的集合外观,仅仅是一种模拟,除了测试以外,没有理由使用内存中真正的集合来创建仓储. 不应该为所有实体建立仓储,只有聚合才拥有仓储. 仓储用来重建已持久化的聚合,而工厂用于新建聚合. 使用仓储的优点 直接使用Entity Framework的DbContext不是很好吗,为什么还要在DbContext的上方封装一层仓储呢,这