Unit Of Work的设计

在DDD开发过程中,一个良好的Uow设计必不可少,我心目中的Uow设计应该具备以下几点:

1、有着良好的抽象,有着恰如其分的命名;

2、能够应付不同的组件,比如你的系统中可能会存在EfUnitOfWork、RedisUnitOfWork;

3、易于使用,不用开发者显示调用。Uow在一个用户请求开始到结束能够自动包裹在业务逻辑外边;

在阅读了Abp的源码后我感觉Abp中的Uow正好符合我这几点要求,但是其实现稍有点复杂,例如在EfUnitOfWork中加入了DynamicFilters,EfUnitOfWork支持多DbContext,这些复杂性导致EfUnitOfWork类变得有点臃肿。所以我在实例代码中移除了这些设计。

一、业务抽象

一个使用Uow的典型代码片段如下:

            using (var uow = UowManager.Begin())
            {
                //....logic

                uow.Commit();
            }

从这段代码中我们基本可以分析出下面的Uow抽象。

1、IUnitOfWorkManager

从上面的代码片段可以看出,此Manager应该具有一个Begin()方法,返回IDisposable类型。

2、IUnitOfWorkCompleteHandle

IUnitOfWorkManager的Begin()方法返回的IDisposable类型应该具有Commit()的能力,该抽象用于对IUnitOfWork的提交和释放资源。

3、IUnitOfWork

从这个代码片段中我们并没有看到IUnitOfWork这个抽象,原因在于IUnitOfWorkManager隐藏了具体的IUnitOfWork,IUnitOfWorkManager.Begin()实现中实际上是具体的IUnitOfWork.Begin()调用。

4、ICurrentUnitOfWorkProvider

针对用户在一次上下文中的请求,具有唯一的一个IUnitOfWork,因此可以在任意时刻通过ICurrentUnitOfWorkProvider来读取当前上下文的IUnitOfWork。

通过接口命名描述就能理清整个Uow设计思路:

二、EfUnitOfWork

EfUnitOfWork的Begin体现在对TransactionScope的调用、Commit体现在对dbContext.SaveChanges()的调用

        public void Begin(UnitOfWorkOptions options)
        {
            _transactionScope = new TransactionScope(
                options.TransactionScopeOption.GetValueOrDefault(_defaultUnitOfWorkOptions.TransactionScopeOption),
                new TransactionOptions()
                {
                    IsolationLevel = options.IsolationLevel.GetValueOrDefault(_defaultUnitOfWorkOptions.IsolationLevel),
                    Timeout = options.Timeout.GetValueOrDefault(_defaultUnitOfWorkOptions.Timeout)
                });
        }
        public void Complete()
        {
            try
            {
                _dbContext.SaveChanges();
                _transactionScope?.Complete();

                _completed?.Invoke();
            }
            catch
            {
                _failed?.Invoke();
                throw;
            }

        }

三、通过Castle实现Aop,将Uow包裹ApplicationService层

定义UnitOfWorkInterceptor,该拦截器表现为要对现有的一个方法包裹UnitOfWork实现。

        private void PerformUow(IInvocation invocation, UnitOfWorkOptions options)
        {
            using (var uow = _unitOfWorkManager.Begin(options))
            {
                invocation.Proceed();
                uow.Complete();
            }
        }

具体实现请参考:https://git.oschina.net/richieyangs/BookLibrary.git

时间: 2024-10-24 21:18:50

Unit Of Work的设计的相关文章

我的“第一次”,就这样没了:DDD(领域驱动设计)理论结合实践

写在前面 插一句:本人超爱落网-<平凡的世界>这一期,分享给大家. 阅读目录: 关于DDD 前期分析 框架搭建 代码实现 开源-发布 后记 第一次听你,清风吹送,田野短笛:第一次看你,半弯新湖,鱼跃翠堤:第一次念你,燕飞巢冷,释怀记忆:第一次梦你,云翔海岛,轮渡迤逦:第一次认你,怨江别续,草桥知己:第一次怕你,命悬一线,遗憾禁忌:第一次悟你,千年菩提,生死一起. 人生有很多的第一次:小时候第一次牙牙学语.第一次学蹒跚学步...长大后第一次上课.第一次逃课.第一次骑自行车.第一次懂事.第一次和喜

Linux系统运维与架构设计

一 本章概览 介绍Linux系统运维与架构设计的方方面面 二 Linux基础入门 认识计算机核心硬件和服务器 Linux发展历史.系统组成.应用领域以及发行版 搭建运维环境:VMWareWorkStation.SecureCRT的使用 Linux系统的基本使用 Shell入门以及命令概述 三 Linux系统管理 文件目录管理 用户管理 权限管理 VIM编辑器的使用 文档压缩打包 程序包管理 网络管理 文件系统管理 内存管理 系统管理(监控.环境变量) 安全管理(selinux,iptables)

【netty】Netty系列之Netty百万级推送服务设计要点

1. 背景 1.1. 话题来源 最近很多从事移动互联网和物联网开发的同学给我发邮件或者微博私信我,咨询推送服务相关的问题.问题五花八门,在帮助大家答疑解惑的过程中,我也对问题进行了总结,大概可以归纳为如下几类: Netty是否可以做推送服务器? 如果使用Netty开发推送服务,一个服务器最多可以支撑多少个客户端? 使用Netty开发推送服务遇到的各种技术问题. 由于咨询者众多,关注点也比较集中,我希望通过本文的案例分析和对推送服务设计要点的总结,帮助大家在实际工作中少走弯路. 1.2. 推送服务

DDD领域驱动设计基本理论知识总结

领域驱动设计之领域模型 加一个导航,关于如何设计聚合的详细思考,见这篇文章. 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD.领域驱动设计分为两个阶段: 以一种领域专家.设计人员.开发人员都能理解的通用语言作为相互交流的工具,在交流的过程中发现领域概念,然后将这些概念设计成一个领域模型:由领域模型驱动软件设计,用代码来实现该领域模型:

异步并行批处理框架设计的一些思考(转)

随着互联网信息技术日新月异的发展,一个海量数据爆炸的时代已经到来.如何有效地处理.分析这些海量的数据资源,成为各大技术厂商争在激烈的竞争中脱颖而出的一个利器.可以说,如果不能很好的快速处理分析这些海量的数据资源,将很快被市场无情地所淘汰.当然,处理分析这些海量数据目前可以借鉴的方案有很多:首先,在分布式计算方面有Hadoop里面的MapReduce并行计算框架,它主要针对的是离线的数据挖掘分析.此外还有针对实时在线流式数据处理方面的,同样也是分布式的计算框架Storm,也能很好的满足数据实时性分

领域驱动设计的面向服务架构

[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店 一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列

《世界杯彩票竞猜系统》设计报告

目录 1 文档介绍    4 1.1 文档目的    4 1.2 文档范围    4 1.3 读者对象    4 1.4 参考文献    5 1.5 术语与缩写解释    5 2 系统环境说明    6 3 需求分析    7 3.1 功能需求分析    7 3.2 非功能需求分析    7 4 数据库的命名规则    8 5 概念结构设计    9 6 逻辑结构设计    9 7 物理结构设计    11 7.1 表汇总    11 7.2 表VS    11 7.3 表team    12

.NET应用架构设计—工作单元模式(摆脱过程式代码的重要思想,逆袭DDD)

阅读目录: 1.背景介绍 2.过程式代码的真正困境 3.工作单元模式的简单示例 4.总结 1.背景介绍 一直都在谈论面向对象开发,但是开发企业应用系统时,使用面向对象开发最大的问题就是在于,多个对象之间的互操作需要涉及数据库操作.两个业务逻辑对象彼此之间需要互相调用,如果之间的互相操作是在一个业务事务范围内的,很容易完成,但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了. 在以往,我们使用过程式的代码(事务脚本模式),将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中

5.1生产信息管理模块的使用和设计

目标 描述生产制造如何设置,释放,完工. 描述如何使用库存维度和组,来管理生产信息. 复习库存维度的数据模型. 介绍 生产是一种项目,服务,或有正确结果的经济活动.在AX2012中,所有的生产数据都在所有公司共享.虚拟表集合的概念,对生产数据不在可用.在早期版本中使用的产品的表现(InventTable),依然存在,并且该表依然被包含在表集合中.然而,它现在有一个外键,指向共享的生产实例(EcoResProduct 层次),并且他代表释放的产品的概念,或一个给定企业制造. 本章高亮新的模式,来代