回到目录 之前我写过关于XMLRepository仓储的实现的文章,主要是针对XElement方式的,对于XML的结构,一般来说有两种,一是使用节点方式的,我习惯称为XElement方式,别一种是属性方式的,我习惯称为XAttribute,这两种方式,我比较取向于后面的,好处就是更简洁,将C#里的类看作节点,而将C#里的属性看作是节点的每个特性(XAttribute),这种方式感觉更容易被人接受! 如果您还看不懂这两方式指的是什么,就看一下两种方式的XML举例吧 XElement方式 <User…

回到目录 对于数据仓储大家应该都很熟悉了,它一般由几个仓储规范和实现它的具体类组成,而仓储的接口与架构本身无关,对于仓储的实现,你可以选择linq2Sql,EF,Nosql,及XML 等等,之前我介绍过linq2Sql,ef和nosql(redis)的仓储实现,今天主要说一下xml仓储的实现. 下面的相关核心代码 XML实体基类 /// <summary> /// XML实体基类 /// </summary> public abstract class XMLEntity { pr…

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

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

DDD分层架构之仓储(层超类型基础篇) 前一篇介绍了仓储的基本概念,并谈了我对仓储的一些认识,本文将实现仓储的基本功能. 仓储代表聚合在内存中的集合,所以仓储的接口需要模拟得像一个集合.仓储中有很多操作都是可以通用的,可以把这部分操作抽取到基类中. 在Util.Domains项目中创建一个文件夹Repositories,这个文件夹用来放仓储相关的接口.在Repositories下创建一个仓储接口IRepository. 把仓储基接口放到Util.Domains,是因为仓储接口是在领域层定义的,这…

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

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

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

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

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