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

回到目录 最近总遇到大数据的问题,一次性处理几千万数据不实际,所以,我们需要对大数据进行分块处理,或者叫分页处理,我在EF架构里曾经写过类似的,那是在进行BulkInsert时,对大数据批量插入时候用到的,现在我把它拿出来,放在IQueryableExtensions类中,即它将作为IQueryable的一个扩展出现,我们可以把这个分页处理的逻辑应用的更加广泛,并且,在这个整理中,提供了异步并行版本,它比同版版本快了几十倍之多,可以说,当前的服务器,只有使用了并且计算之后,才能发挥它的作用! /…

回到目录 返回异步与并行目录 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这块,实现异步(并行…

回到目录 规约(Specification)模式:第一次看到这东西是在microsoft NLayer项目中,它是微软对DDD的解说,就像petshop告诉了我们MVC如何使用一样,这个规约模式最重要的作用是实现了查询语句与查询条件的分离,查询语句在底层是稳定的,不变的,而查询条件是和具体业务,具体领域有关的,是易变的,如果我们为每一个领域的每一个新需求都写一个新的方法,那就会出现很多重复的代码,不利于程序的最终扩展! 下面我们来看一个经典例子 一个IOrderRepository的接口,定义了…

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

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

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

回到目录 对于大数据量提交,包括插入,更新和删除,我始终不建议用EF自带的方法,因为它会增加与数据库的交互次数,一般地,EF的一个上下文在提交时会打开一个数据连接,然后把转换成的SQL语句一条一条的发到数据库端,然后去提交,试想,如果你的数据量达到万级别(更不用说百万,千万数据了),那对数据库的压力是很大的,所以,我将EF批量操作语句进行了改版,并起名为BulkInsert,BulkUpdate和BulkDelete,事实上,在我之前的版本中并没有涉及到批次提交的概念,直到遇到了实际的问题,当你…

回到目录 本文介绍两个概念,防数据库自动删除,这是由于在code first模式下,当数据实体发生变化时,会对原来数据库进行删除,并将新数据表添加进来,但这对于我们的运营环境数据库,是万万不能接受的,第二个问题是数据迁移问题,当你有新的实体建立后,如何响应到数据库,这成为一个问题,当然实现也很简单,我们直接使用migrations工具即可. 一 防数据库删除 将你的业务DbInitializer的基类改成CreateDatabaseIfNotExists即可解决这个问题,这是在数据初始化时需要做…

回到目录 Migrations即迁移,它是EF的code first模式出现的产物,它意思是说,将代码的变化反映到数据库上,这种反映有两种环境,一是本地开发环境,别一种是服务器的生产环境,本地开发环境主要使用包管理工具的update-database即可完成数据库的迁移(变更),而在生产环境就显得麻烦一些,因为你不会在生产环境放程序源代码和VS开发工具,哈哈． 本地数据库迁移请看我的这篇文章 EF架构~CodeFirst数据迁移与防数据库删除 服务器上生产环境的数据迁移 如果我们有迁移文件如下…