EF架构~EF异步改造之路~仓储接口的改造~续

回到目录

在写完仓储接口的改造改造后,总觉得有个代码的坏味道,这种味道源于它的DRP,即重复的代码太多了,即异步操作和同步操作其实只是在insert,update和delete上有所不同,获取数据的方法都是一样的,所以,我最后决定,将异步的接口进行改造,让它更加合理,方法后都加上Async的后缀,看上去也更像是个异步方法,呵。

改造后的异步接口

  /// <summary>
    /// 异步操作
    /// 基础的数据操作规范
    /// 与ORM架构无关
    /// </summary>
    /// <typeparam name="TEntity"></typeparam>
    public interface IRepositoryAsync<TEntity>
           where TEntity : class
    {

        /// <summary>
        /// 添加实体并提交到数据服务器
        /// </summary>
        /// <param name="item">Item to add to repository</param>
        Task InsertAsync(TEntity item);

        /// <summary>
        /// 移除实体并提交到数据服务器
        /// 如果表存在约束,需要先删除子表信息
        /// </summary>
        /// <param name="item">Item to delete</param>
        Task DeleteAsync(TEntity item);

        /// <summary>
        /// 修改实体并提交到数据服务器
        /// </summary>
        /// <param name="item"></param>
        Task UpdateAsync(TEntity item);

        /// <summary>
        /// 添加集合[集合数目不大时用此方法,超大集合使用BulkInsert]
        /// </summary>
        /// <param name="item"></param>
        Task InsertAsync(IEnumerable<TEntity> item);

        /// <summary>
        /// 修改集合[集合数目不大时用此方法,超大集合使用BulkUpdate]
        /// </summary>
        /// <param name="item"></param>
        Task UpdateAsync(IEnumerable<TEntity> item);

        /// <summary>
        /// 删除集合[集合数目不大时用此方法,超大集合使用批量删除]
        /// </summary>
        /// <param name="item"></param>
        Task DeleteAsync(IEnumerable<TEntity> item);
        /// <summary>
        /// 批量添加,添加之前可以去除自增属性,默认不去除
        /// </summary>
        /// <param name="item"></param>
        /// <param name="isRemoveIdentity"></param>
        Task BulkInsertAsync(IEnumerable<TEntity> item, bool isRemoveIdentity);

        /// <summary>
        /// 批量添加
        /// </summary>
        /// <param name="item"></param>
        Task BulkInsertAsync(IEnumerable<TEntity> item);

        /// <summary>
        /// 批量更新
        /// </summary>
        /// <param name="item"></param>
        Task BulkUpdateAsync(IEnumerable<TEntity> item, params string[] fieldParams);

        /// <summary>
        /// 批量删除
        /// </summary>
        /// <param name="item"></param>
        Task BulkDeleteAsync(IEnumerable<TEntity> item);
    }

而原来的IExtendRepository同步去继承同步和异步两个仓储接口

而在调用上,开发者们更清楚自己使用的是同步还是异步方法

回到目录

时间: 2024-08-12 23:04:36

EF架构~EF异步改造之路~仓储接口的改造~续的相关文章

EF异步改造之路~第一回 仓储接口的改造

C#5.0带来了并行编程 {C#1.0托管代码→C#2.0泛型→C#3.0LINQ→C#4.0动态语言→C#5.0异步编程} 随着C#5.0在.net4.5出来之后,它们主推的并行技术也逐渐变得越来越热,这种热量已经传到了我这里,身为仓储大叔的我,一定也对自己的仓储进行并行化的改造,这是大势所趋,呵呵,今天主要是把我的IRepository.Core项目进行扩展,即添加一些对应的并行接口,然后让我的并行(异步)仓储去实现它,事实上,.net的ef这块,实现异步(并行)非常容易,在C#5.0里由于

EF架构~基于EF数据层的实现

回到目录 之前写过关于实现一个完整的EF架构的文章,文章的阅读量也是满大的,自己很欣慰,但是,那篇文章是我2011年写的,所以,技术有些不成熟,所以今天把我的2014年写的EF底层架构公开一下,这个架构比2011年的有了很大程度的提高,主要在接口规范,查询规范上,并引入了排序功能,两步对完善了EF对数据的批量操作,可以说,这次的架构是很有看点的. 一 一个基础操作接口 /// <summary> /// 基础的数据操作规范 /// 与ORM架构无关 /// </summary> /

第四十回 EF架构~LinqToEntity里实现left join的一对一与一对多

回到目录 对于linq to sql里实现left join我已经介绍过了,这篇文章的出现是由于最近在项目里遇到的一个问题,解决这个问题花了我不少时间,可能有2个小时,事件是这样的,对于两个表,它们是一对多关系,而需求是返回一个一对一的关系,并将最新的数据返回,这个很多同学都知道,可以使用inner join,但是,对于inner  join来说,当处理的是一对多关系时,它将会出现多条记录,这也是正常的:而它并不满足我们今天的需求,经过测试后,找到了解决这个问题的方法,下面看代码: 一对多关系

EF架构~通过EF6的DbCommand拦截器来实现数据库读写分离~终结~配置的优化和事务里读写的统一

回到目录 本讲是通过DbCommand拦截器来实现读写分离的最后一讲,对之前几篇文章做了一个优化,无论是程序可读性还是实用性上都有一个提升,在配置信息这块,去除了字符串方式的拼接,取而代之的是section数组,这样在修改配置时更加清晰了:而实用性上,彻底改变了读和写不能共用一个仓储对象的缺点,并且在一个事务里可以读写并存,并为了数据的一致性,使事务里的curd操作指向主库,这一点很重要! 前几篇文章的目录 EF架构~通过EF6的DbCommand拦截器来实现数据库读写分离~再续~添加对各只读服

EF架构~在Linq to Entity中使用日期函數

回到目录 眾所周知,在linq to entity的查询语句中,不允许出现ef不能识别的关键字,如Trim,Substring,TotalDays等.net里的关键字,在EF查询里都是不被支持的,它的原因可能是为了更好的提高查询的性能吧,毕竟,好的性能取决于你的程序标准,有了一个严格的标准,才能设计出好的程序来. 今天主要说一下,EF为日期方法留的一个后门,<后门>这个词大家在中国社会都应该知道了,顾名思义,就是反着原则走,你的原则对我没有用,哈哈!这东西有时候是有用的,因为在大的原则下,很可

EF架构~过滤导航属性等,拼接SQL字符串

拼接T-SQL串,并使它具有通用性 好处:与服务器建立一次连接,给服务器发一条SQL命令,即可实现 代码如下: 1 /// <summary> 2 /// 构建Insert语句串 3 /// 主键为自增时,如果主键值为0,我们将主键插入到SQL串中 4 /// </summary> 5 /// <typeparam name="TEntity"></typeparam> 6 /// <param name="entity&

EF架构~为EF DbContext生成的实体添加注释(T5模板应用)

相关文章系列 第八回 EF架构~将数据库注释添加导入到模型实体类中 第二十一回  EF架构~为EF DbContext生成的实体添加注释(T4模板应用) 第二十二回EF架构~为EF DbContext生成的实体添加注释(T5模板应用) 嗨,没法说,EF4的TT模版加上注释后,升级到EF5的TT模版后,注释就不通用了,所以,还得再研究一下,然后把操作方法再分享出来,没辙的微软! T4模版可能有些凌乱,这在T5模版里有了不错的改进,但我希望解决的问题在T5里并没有得到解决,那就是TT类文件自动得到E

EF架构~豁出去了,为了IOC,为了扩展,改变以前的IRepository接口

回到目录 使用了4年的IRepository数据仓储接口,今天要改变了,对于这个数据仓储操作接口,它提倡的是简洁,单纯,就是对数据上下文的操作,而直正的数据上下文本身我们却把它忽略了,在我的IRepository接口里根本没有数据上下文对象,这是不完整的,也许你会说,我使用了基类,数据基类里有数据上下文,是的,我也是那样用的,但有时,这种方法有些死板了,真的,当你碰到IOC时,这种方式的短板就出来了,即,每个反射出来的Repository对象都是独立的,每个对象里的上下文也都是独立的,这是重点,

云架构师的进阶之路

原文:云架构师的进阶之路 一.架构的三个维度和六个层面 1.1.三大架构 在互联网时代,要做好一个合格的云架构师,需要熟悉三大架构. 第一个是IT架构,其实就是计算,网络,存储.这是云架构师的基本功,也是最传统的云架构师应该首先掌握的部分,良好设计的IT架构,可以降低CAPEX和OPEX,减轻运维的负担.数据中心,虚拟化,云平台,容器平台都属于IT架构的范畴. 第二个是应用架构,随着应用从传统应用向互联网应用转型,仅仅搞定资源层面的弹性还不够,常常会出现创建了大批机器,仍然撑不住高并发流量.因而