ddd java repository_初探领域驱动设计(2)Repository在DDD中的应用
概述
上一篇我们算是粗略的介绍了一下DDD,我们提到了实体、值类型和领域服务,也稍微讲到了DDD中的分层结构。但这只能算是一个很简单的介绍,并且我们在上篇的末尾还留下了一些问题,其中大家讨论比较多的,也是我本人之前有一些疑问的地方就是Repository。我之前觉得IRepository和三层里面的IDAL很像,为什么要整出这么个东西来;有人说用EF的话就不需要Repository了;IRepository是鸡肋等等。 我觉得这些问题都很好,我自己也觉得有问题,带着这些问题我们就来看一看Repository在DDD中到底起着一个什么样的角色,它为什么存在?有一句真理不是说“存在即合理”么? 那我们就要找到它存在的理由,去更好的理解它,或者说我们能不能针对不同的需求去改造它呢?注:本文讨论的是Repository在DDD中的应用,与EF该不该用Repoistory不是同一个话题。
领域驱动系列
目录
EF与Repository
在上一篇《初探领域驱动设计(1)为复杂业务而生》中,我们已经实现了一个用户注册的例子,但是并不完整。我们还没有具体的实现Repository,即使是在测试的时候我们使用的也是一个Mock。那么今天,我们就来实现一个EntityFramework的Repository。有人说EF没有必要套一个Repository,我是同意的。但是不同的场景,不同的使用方法,我们下面再具体讲。我们在上一篇中已经提到了IRepository的接口定义,下面是我们的简单实现:
// EFRepository.cs
1 namespaceRepositoryAndEf.Data2 {3 public class EfRepository : IRepository whereT : BaseEntity4 {5 privateDbContext _context;6
7 publicEfRepository(DbContext context)8 {9 if (context == null)10 {11 throw new ArgumentNullException("context");12 }13 _context =context;14 }15
16 publicT GetById(Guid id)17 {18 return _context.Set().Find(id);19 }20
21 public boolInsert(T entity)22 {23 _context.Set().Add(entity);24 _context.SaveChanges();25 return true;26 }27 public boolUpdate(T entity)28 {29 _context.Set().Attach(entity);30 _context.Entry(entity).State =EntityState.Modified;31 _context.SaveChanges();32 return true;33 }34
35 public boolDelete(T entity)36 {37 _context.Set().Remove(entity);38 _context.SaveChanges();39 return true;40 }41
42
43 public IEnumerable Get(Expression>predicate)44 {45 return _context.Set().Where(predicate).ToList();46 }47 }48 }
View Code
// 应用层UserService.cs
1 public classUserService : IUserService2 {3 private IRepository_userRepository;4
5 public UserService(IRepositoryuserRepository)6 {7 _userRepository =userRepository;8 }9
10 public User Register(string email, string name, stringpassword)11 {12 var domainUserService = newDomain.UserService(_userRepository);13 var user =domainUserService.Register(email, name, password);14 returnuser;15 }16 }
View Code
// 领域层UserService.cs
1 namespaceRepositoryAndEf.Domain2 {3 public classUserService4 {5 private IRepository_userRepository;6
7 public UserService(IRepositoryuserRepsoitory)8 {9 _userRepository =userRepsoitory;10 }11
12 public virtual User Register(string email, string name, stringpassword)13 {14 if (_userRepository.Get().Any(u => u.Email ==email))15 {16 throw new ArgumentException("The email is already taken");17 }18
19 var user = newUser20 {21 Id =Guid.NewGuid(),22 Email =email,23 Name =name,24 Password =password25 };26
27 user.CreateShoppingCart();28 _userRepository.Insert(user);29 returnuser;30 }31 }32 }
View Code
上面领域层UserService中的代码和我们上一篇中的代码是一样的,netfocus兄提出来一个问题“是不是把user对象加入到repository中就算完成注册了?” 现在看来,如果代码这样写,好像就已经完成了注册的功能。 但是如果真这样写,我又觉得问题更大,也就是为什么我会在上篇的未必留下那个问题,“Domain -> Repository -> Database” 和“BLL -> Dal -> Database” 有区别么?撇开这个问题不说,看看我们上面的EfRepository有没有什么问题? 好用么?现在好像没有办法使用事务啊!带着这个问题我们来看看Unit Of Work能怎么帮我们。
Unit Of Work 与 Repository
我们EfRepository的实现中,每一次Insert/Update/Delete操作被执行之后,变更就会立即同步到数据库中去。第一,我们没有为多个操作添加一个事务的能力;第二,这会为我们带来性能上的损失。而Unit Of Work模式正好解决了我们的问题,下面是Martin Fowler 对于该模式的解释:
“A Unit of Work keep track of everything you do during a business transaction that can affect the database. When you’re done, it figures out everything that need to be done to alter the database as a result of your work.”
Unit of Work负责跟踪所有业务事务过程中数据库的变更。当事务完成之后,它找出需要处理的变更,并更新数据库。
正如我们大家一直讨论的那样,在EF中,DBContext它本身就已经是一个Unit Of Work的模式,因为上面说的功能它都有。那我们有必要自己再给它包上一层吗?我的答案是肯定的,这个和我们为Repository建立接口是一样的,EF中的IDbSet就是一个Repository模式,但是他们都是EF里面的东西,如果哪天我们换成NHibernate了,我们不可能为了这一个接口和基类把EF这个dll也加进来是么? 我们要做的并不多,因为DbContext.SaveChanges它本身就是有事务的,所以我们只需要创建一个带有SaveChanges的接口就可以了。
// IUnitOfWork.cs
1 namespaceRepositoryAndEf.Core.Data2 {3 public interfaceIUnitOfWork : IDisposable4 {5 intSaveChanges();6 }7 }
View Code
接着就是让我们的Context,继承DbContex和我们上面的接口。
1 namespaceRepositoryAndEf.Data2 {3 public classRepositoryAndEfContext : DbContext, IUnitOfWork4 {5 publicRepositoryAndEfContext() { }6
7 public RepositoryAndEfContext(stringnameOrConnectionString)8 : base(nameOrConnectionString)9 {10 Configuration.LazyLoadingEnabled = true;11 }12
13 protected override voidOnModelCreating(DbModelBuilder modelBuilder)14 {15 var typesToRegister =Assembly.GetExecutingAssembly().GetTypes()16 .Where(type => !String.IsNullOrEmpty(type.Namespace))17 .Where(type => type.BaseType != null
18 &&type.BaseType.IsGenericType19 && type.BaseType.GetGenericTypeDefinition() == typeof(EntityTypeConfiguration<>));20
21 foreach (var type intypesToRegister)22 {23 dynamic configurationInstance =Activator.CreateInstance(type);24 modelBuilder.Configurations.Add(configurationInstance);25 }26 //...or do it manually below. For example,27 //modelBuilder.Configurations.Add(new LanguageMap());
28
29 base.OnModelCreating(modelBuilder);30 }31 }32 }
View Code
哦,对了,别忘了把Repository里面的SaveChanges方法去掉。
1 namespaceRepositoryAndEf.Data2 {3 public class EfRepository : IRepository whereT : BaseEntity4 {5 privateDbContext _context;6
7 publicEfRepository(IUnitOfWork uow)8 {9 if (uow == null)10 {11 throw new ArgumentNullException("uow");12 }13 _context = uow asDbContext;14 }15
16 publicT GetById(Guid id)17 {18 return _context.Set().Find(id);19 }20
21 public boolInsert(T entity)22 {23 _context.Set().Add(entity);24 return true;25 }26
27 public boolUpdate(T entity)28 {29 _context.Set().Attach(entity);30 _context.Entry(entity).State =EntityState.Modified;31 return true;32 }33
34 public boolDelete(T entity)35 {36 _context.Set().Remove(entity);37 return true;38 }39
40
41 public IEnumerable Get(Expression>predicate)42 {43 return _context.Set().Where(predicate).ToList();44 }45 }46 }
View Code
那么我们应用层的UserService就可以这样写了。
namespaceRepositoryAndEf.Service
{public classUserService : IUserService
{private IRepository_userRepository;private IUnitOfWork _uow =EngineContext.Current.Resolve();public UserService(IRepositoryuserRepository)
{
_userRepository=userRepository;
}public User Register(string email, string name, stringpassword)
{var domainUserService = newDomain.UserService(_userRepository);var user =domainUserService.Register(email, name, password);//在调用SaveChnages()之前,做其它的更新操作//它们会一起在同一个事务中执行。
_uow.SaveChanges();returnuser;
}
}
}
View Code
如果光看这段代码有没有觉得很奇怪?没有任何对_userRepository的操作,就做了SaveChanges,因为我们在领域服务里面就已经把新创建的用户实体放到那个userRepository中去了。我想这个问题@田园的蟋蟀纠结过很久:) ,也就是领域服务那里面持有repository的引用,它可以自己将要更新的实体添加到repository中,但是如果对于一些不涉及到领域服务的操作,那这一点就需要在应用层来做了,比如添加商品到购物车的操作。
// 应用层ShoppingCartService.cs
1 namespaceRepositoryAndEf.Service2 {3 public classShoppingCartService : IShoppingCartService4 {5 private IRepository_shoppingCartRepository;6 private IRepository_productRepository;7 privateIUnitOfWork _uow;8
9 publicShoppingCartService(IUnitOfWork uow,10 IRepositoryshoppingCartRepository,11 IRepositoryproductRepository)12 {13 _uow =uow;14 _shoppingCartRepository =shoppingCartRepository;15 _productRepository =productRepository;16 }17
18 publicShoppingCart AddToCart(Guid cartId,19 Guid productId,20 intquantity)21 {22 var cart =_shoppingCartRepository.GetById(cartId);23 var product =_productRepository.GetById(productId);24 cart.AddItem(product, quantity);25
26 _shoppingCartRepository.Update(cart);27 _uow.SaveChanges();28 returncart;29 }30 }31 }
View Code
这就是属于职责定义不明确的问题,特别是上面注册用户的例子。应用层也有_userRepository,并且领域服务还给我返回了一个user的实体,那我是把它加到这个_userRepository中呢还是不加好呢?
我觉得我们应该有这样的一个定义,在领域层那里不使用repository的更新类操作(即Insert/Update/Delete),只使用查询类操作即(GetById,或者是Get)。把所有的更新类操作都放到应用层,这样由应用层去决定什么时候把实体更新到repository,以及什么时候去提交到数据库中。那我们就彻底与持久层,甚至领域实体生命期管理的功能撇开有关系了,从此用更OO的方式专注于业务。
后面我们要做的更改就是把_userRepository.Insert(user)从我们User的领域服务中移除掉,并且在应用层的Register方法中加入这句话。 我想到这里,也算是回答了我自己的问题: IRepository正如它的名字一样,它就像一个容器,允许我们把东西放进去或者取出来,它离真正的数据库还有一步之遥,并且通过Unit Of Work,把对事务以及持久化的控制都交到了外面。而不是像DAL那样直接就反映到数据库中去了。除此之外呢?IRepository解除了领域层对基础设施层的依懒,这个也是大家经常提到了Repository的优点之一。但是未必这一点一定非得需要IRepository,把IDAL接口移个位置同样也可以实现,不信您看看洋葱架构。
洋葱架构与IRepository
洋葱架构很早就有,只不过08年的时候Jeffery给它取了个名字,让它成为了一个模式。说起来好像很高大上,但是希望大家不要被这些名字所迷惑,所正如Jeffery所说,在这种设计有了一个名字之后,更方便大家去讨论和传播以及使用这种模式。 并且洋葱架构也是一种多层架构,所以会出现“传统” 的多层架构 和“现代”的多层架构。 我更是认为,所谓的洋葱架构只是作出了一点点思想层面上的转变,仅此而已。 究竟是哪一点思想上的转变,可以让它成为一种模式呢? 依懒关系!
Jeffery说在传统的多层架构中,上层对下层有着较强的依懒关系,UI没了BLL就没法工作,BLL少了DAL也无法正常运行。当然他说这句话的时候是08年,并且他的确是在前面加了“传统” 两个字。 我们很难找到到底是什么时候,这种传统的多层架构演变成了“现代” 的多层架构,但是我们能知道的是在08年7月以后我们对于多层架构又有了一个新的名词。即便如此,它的转变却是非常简单的 —— 也就是把IDAL接口从DAL层分离出去。
如果把IDAL接口定义在DataAccess层,第一是造成了BLL对DataAccess的依懒;第二是造成了IDAL的责任不明确。如果说小A负责开发BLL,小C负责开发DAL,他们是不是需要协调该怎么样去定义IDAL接口? 是DAL为BLL服务,还是BLL的最终目地是把自己移交给DAL? 在最开始的时候,大家对IDAL的定义是为了支持不同的访问层设计,大家想的都是现在我们用SQL,将来有可能会有MySql。所以IDAL放在哪里也就无所谓了,为了方便就直接和实现一起放在DAL吧。
把IDAL接口从DAL移出去之后会发生什么 ?
在把IDAL接口移到BLL层之后,箭头的方向就变了。现在一切都是以BLL为中心,BLL也不需要依懒于任何其它层了,作为独立的一块,我们可以更容易的进行单元测试,重构等。另外也明确了IDAL是为BLL服务的,也就是解决了我们上面提到的第二个问题。
这个一个很简单的转变就是洋葱架构的主要思想,如果你还不能很好的领悟洋葱架构和传统多层架构之间的区别,希望下面这张图能用最直接,最简单的方式告诉你。
传统多层架构与现代(洋葱架构)多层架构的区别
你要是愿意,把IDAL直接放到Bll里面也是可以的。当Jeffery给这种架构起名叫“洋葱架构”再往前推4年,DDD问世的时候已经包含了这种思想。IRepository属于领域层而非基础架构层中的数据访问模块,就直接避免了领域层对基础设施层的依懒,或者说不定这种思想也是从DDD引申出来的,所以你会发现很多人现在依然用DAL。但是并没有什么问题,因为在这种新的多层架构下,扩展性和可维护性同样也可以被保持的很好。
重新定义IRepository
现在,我们再回过头去看Repository。它的两大职责:
对领域实体的生命周期进行管理(从数据库重建,以及持久化到数据库) ——被推迟到了应用层
解除领域层对基础设施的依懒
在第一点生效后,所有更新类的操作都推迟到应用层去执行。那IRepository中的那些更新类方法放在领域层是不是就多余了呢? 毕竟我们现在只需要用到查询的功能。我们可以单独建一个IQuery的接口给领域层使用。
// IQuery.cs
1 namespaceRepositoryAndEf.Core.Data2 {3 public interface IQuery
4 {5 T GetById(Guid id);6 IQueryable Table { get; }7 }8 }
View Code
// IRepository.cs
1 namespaceRepositoryAndEf.Core.Data2 {3 public partial interface IRepository:4 IQuery whereT : BaseEntity5 {6 boolInsert(T entity);7 boolUpdate(T entity);8 boolDelete(T entity);9 }10 }
View Code
我们直接让IRepository继承了IQuery,IQuery就相当于IRepository的一个功能子集,只提供读的功能。 而在EfRepository中,我们只要暴露DbSet.AsQueryAble()就可以了。
// EfRepository IQuery的实体部分
1 publicT GetById(Guid id)2 {3 return _context.Set().Find(id);4 }5
6 public IQueryableTable7 {8 get
9 {10 return _context.Set().AsQueryable();11 }12 }
View Code
// 领域层 UserService.cs
1 namespaceRepositoryAndEf.Domain2 {3 public classUserService4 {5 private IQuery_userQuery;6
7 public UserService(IQueryuserQuery)8 {9 _userQuery =userQuery;10 }11
12 public virtual User Register(string email, string name, stringpassword)13 {14 if (_userQuery.Table.Any(u => u.Email ==email))15 {16 throw new ArgumentException("The email is already taken");17 }18
19 var user = newUser20 {21 Id =Guid.NewGuid(),22 Email =email,23 Name =name,24 Password =password25 };26
27 user.CreateShoppingCart();28 returnuser;29 }30 }31 }
View Code
// 客户端调用应用层Service代码
1 var uow = new RepositoryAndEfContext("ConnStr");2 var userRepository = new EfRepository(uow);3 var userService = newUserService(uow, userRepository);4 var newUser =userService.Register(5 "hellojesseliu@outlook.com",6 "Jesse Liu",7 "jesseliu");
View Code
现在,恐怕你再想在领域模型里面去使用Repository的更新类操作也不行了吧。 Table作为IQueryable返回,那我们想怎么查就随意了。因为是IQueryable,所以也是只会返回我们所查询的内容,和直接用EF查询是一个道理。下面是我们_userQuery.Table.Any()所生成的SQL语句。
1 exec sp_executesql N'SELECT2 CASE WHEN ( EXISTS (SELECT3 1 AS [C1]4 FROM [dbo].[Users] AS [Extent1]5 WHERE ([Extent1].[Email] = @p__linq__0) OR (([Extent1].[Email] IS NULL) AND (@p__linq__0 IS NULL))6 )) THEN cast(1 as bit) ELSE cast(0 as bit) END AS [C1]7 FROM ( SELECT 1 AS X ) AS [SingleRowTable1]',N'@p__linq__0 nvarchar(4000)',@p__linq__0=N'hellojesseliu@outlook.com'
View Code
可有可无的Repository
我们把IRepository移出领域层之后,再加上我们对洋葱架构的理解。我们就可以知道Repository在应用层已经可以被替换成别的东西,IDAL也可以啊:)。当然有人也许会建议直接拿EF来用多好,其实我不建议这样去做,考虑到以后把EF换掉的可能性。并且我们加这样一个接口真的不会碍着我们什么事。如果有人觉得在读取数据的时候加一个Repository在中间,少掉了很多EF提供的功能,觉得很不爽,倒是可以试试像我们的IQuery接口一样直接对DbSet来查询。我们甚至可以学习CQRS架构,将“读”的服务完全分离开,我们就可以单独针对“读”来独立设计。
但是Repository给我们带来的优点,这些优点也是我们不能轻易丢掉它的原因:
提供一个简单的模型,来获取持久对象并管理期生命周期
把应用和领域设计从持久技术、多种数据库策略解耦出来
容易被替换成哑实现(Mock)以便我们在测试中使用
如果你的项目属于短期的项目,或者说你不用考虑更换数据访问层,那么你就可以忽略第一和第二个优点。而第三个优点,借助于一些测试框架我们也可以实现,所以如果你不想用Repository,那就不用,前提条件是你所做的项目允许你这样做,并且你也能够找到好的替代方案来弥补Repository的优势。比如说对洋葱架构中的IDAL再进行一些改造等等。关于更多单元测试的话题,我们将在下一篇中一起来探讨。如果大家对Repository有什么其它的看法,也欢迎一起参与讨论。
ddd java repository_初探领域驱动设计(2)Repository在DDD中的应用相关推荐
- 初探领域驱动设计(1)为复杂业务而生
概述 领域驱动设计也就是3D(Domain-Driven Design)已经有了10年的历史,我相信很多人或多或少都听说过这个名词,但是有多少人真正懂得如何去运用它,或者把它运用好呢?于是有人说,DD ...
- DDD(Domain Driven Design) 领域驱动设计从理论到实践 四
- 接上 SOA 架构 面向服务架构(Service Oriented Architecture,SOA)对于不同的人来说意思不同.这里梳理一下SOA原则: 服务契约 : 通过契约文档,服 ...
- 初探领域驱动设计(Domain Driven Design)
前言: 我个人在学习DDD的过程中,早期翻找各种资料的时候,看到了很多名词:战略设计.战术设计.聚合根.实体.值对象.界限上下文...这些繁多的名词定义配合上几乎少的可怜的实战例子,让我在翻阅了大量资 ...
- 领域驱动设计学习之路—DDD的原则与实践
本文是我学习Scott Millett & Nick Tune编著的<领域驱动设计模式.原理与实践>一书的学习笔记,一共会分为4个部分如下,此文为第1部分: 领域驱动设计的原则与实 ...
- 【笔记】DDD领域驱动设计精粹——浅谈DDD
前言:` 前不久,在工作中使用DDD(领域驱动设计)完成对系统架构和功能的重构,前期参考了很多DDD文章讨论了战略设计划分好模型和领域,然后使用战术设计落实整个项目的重构,重构期间学到了很多DDD的思 ...
- ddd 访问权限_DDD领域驱动设计实战 - 创建实体身份标识的常用策略
从简单到复杂依次为: 3.1.1 用户提供唯一标识 这时用户将输入一些可识别的数值或符号,或从已有标识中选其一,然后创建实体对象.这是一种非常简单方案,但也可能变得复杂. 由于需用户自己生成高质量的标 ...
- DDD领域驱动设计-为什么要用DDD
如果你有以下的疑问,那你可以试试领域驱动设计. 当朋友和你聊项目时,你能否一语中的,说清你在开发中的业务内容及其价值? 当产品和你聊需求时,是否遇到过反复沟通之后才发现讲的不是同个东西的情况? 当你在 ...
- DDD(domain driven design)-领域驱动设计
domain driven design-领域驱动设计 领域驱动设计概述 背景 软件架构模式的演进 概念 分层架构与六边形架构 分层分包 复杂是我们软件生涯的一生之敌. 分层架构 & 面向过程 ...
- ABP入门教程(四)初探领域驱动设计
ABP项目的分层 .Application 为应用层:构建服务 .Core 为领域层:定义实体,定义实体功能,实现实体功能,定义仓储接口 .EntityFrameworkCore 为数据库处理(EF层 ...
最新文章
- 免费公开课 | 数据科学家,从入门到精进!【今晚福利】
- php t string,PHP中出现意外的T_STRING错误
- linux定时备份mysql_linux定时备份MySQL数据库并删除七天前的备份文件
- [我给Unity官方视频教程做中文字幕]beginner Graphics – Lessons系列之材质了解Materials...
- Vue-自定义表单验证
- 2018 Multi-University Training Contest 7 - GuGuFishtion
- tomcat优化实例
- CSS/HTML/JS
- vs2015-devexpress 安装
- keytool基本使用
- 什么是BS,BS和CS的区别有哪些:
- Editor: 维护一个整数编辑器 HDOJ4699
- 此beta版已额满_天龙八部荣耀版 新手升级指南
- 星级评分原理 N次重写的分析
- Regionals 2014 Asia - Daejeon
- unity支持的模型数据格式,unity3d模型制作规范
- 前端 vue 使用高德地图组件:(二)获取鼠标点击位置坐标 和 图标覆盖物拖动后的坐标
- F1 Delta Time 大奖赛每日挑战赛开启
- 数据挖掘——关联规则挖掘
- 教你怎么在电脑上玩《代号:Ace》手游,《代号:Ace》二次元吃鸡手游电脑版教程