Repository、IUnitOfWork
2015-10-17 22:42
399 查看
Repository、IUnitOfWork 在领域层和应用服务层之间的代码分布与实现
本来早就准备总结一下关于Repository、IUnitOfWork之间的联系以及在各层中的分布,直到看到田园里的蟋蟀发表的文章:《DDD 领域驱动设计-谈谈 Repository、IUnitOfWork 和 IDbContext 的实践》,才觉得有必要发表一下我个人的观点及其相关的实现代码,当然我的观点不一定就比他们的好,我只是表达个人观点而矣,大家勿喷。关于Repository可以看看DUDU的这篇文章:关于Repository模式,我结合实际应用总结其核心概念为:Repository是受领域驱动及基于领域的意图对外(领域服务、领域实体、应用服务层)提供管理实体的服务,本身不对数据的持久化负责,也不应该出现未受领域约束的方法。
关于Unit Of Work,我认为它的作用是:管理数据持久化的问题,并不受外界影响(比如:并发)确保在同一个工作单元(或者说是同一个业务领域)下操作的一致性(即:要么都成功,要么就都失败),类似事务;
Entity Framework的DbContext其实就实现了Unit Of Work的功能(比如:SET用来查询数据,同时通过SET的Add及Remove向DbContext注册增加及删除的请求服务,对于更新则是通过自动适时追踪来实现的,只有通过SaveChanges才将实体的状态执行化到数据库中),于是关于在使用Entity Framework后有没有必要再实现Unit Of Work,博客园的大牛们都有过争论,我觉得应该依项目的实际情况来定,如果项目简单且不考虑更换其它数据库以及单元测试的便利性,那么直接使用DbContext就OK了,但如果不是,那么就需要用到Unit Of Work+Repository来包装隔离实际的持久化实现。
对于Repository、IUnitOfWork 在领域层和应用服务层之间的关联与代码分布,我采用如下图方式:
下面就来分享我关于Repository、IUnitOfWork 实现代码:
Exam.Domain.IUnitOfWork定义:
Exam.Domain.Repositories.IRepository定义:
Exam.Repositories.IDbContext定义:
/article/5337708.html
Exam.Repositories.Repository的定义:
订单与订单项,订单应为聚合根,订单项应为实体或值对象,为什么这么说呢?
1.先有订单存在,才会有订单项;
2.订单项不允许单独自行删除,若要删除需通过订单来执行,一般要么订单创建,要么订单删除,不存在订单生成后,还要去删除订单项的,比如:京东的订单,你去看看生成订单后,还能否在不改变订单的情况下删除订单中的某个物品的。
3.订单查询出来了,相应的订单项也就知道了,不存在只知道订单项,而不知道订单的情况。
描述的可能还不够准确,但综上所述基本可以确定聚合关系,而且若使用了EF,它的自动跟踪与延迟加载特性也会为实现聚合根带来方便,当然了也可以自行实现类似EF的自动跟踪与延迟加载功能,已经有人实现了类似功能,可以看netfocus相关文章。
下面是演示示例:
标签: DDD, UnitOfWork, Repository
相关文章推荐
- 3D游戏与计算机图形学中的数学方法-点线面
- python_7(索引、切片)
- Linux中ACL权限管理
- 关键字测试录制一般步骤
- Nginx 的安装, 环境是CentOS
- 让Windows 10更适合平板工作环境——休眠分区和Intel Rapid Start Techn
- 程序设计思想之一直添加
- 黑马程序员_http请求响应参数解读
- Hadoop基础知识(二)
- memcached和memcache的区别
- KVM - 通过虚拟磁盘恢复虚拟机
- 黑马程序员_正则表达式
- linux下sprintf_s函数的替代(转载)
- 脚手架理论与曲线理论
- if语句
- java基础-泛型学习
- MapReduce的核心资料索引 [转]
- KVM - 虚拟磁盘扩容
- KVM - 虚拟磁盘扩容
- 从阿里走出来的创业公司,将如何颠覆大数据产业?