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

回到目录 在之前写的DDD~基础设施层文章中,提到了UnitOfWork,它里面有一些方法,但经过项目证明,不应该有Save和IsExplicitSubmit,而这个工作单元只起到了数据上下文统一的作用,如A和B对象需要在同一个上下文中工作,这时,我们可以引用工作单元的概念,而对于保存和提交操作,还是应该在局部方法里完成的. 为了不去触发MSDTC,我会封装一个特殊的事务,来实现这个工作,而对于SQL2008来说,可以直接使用.net自己的TransactionScope实现,对于同一个数据库来

最近趁着不忙,在构思一个搭建一个开源的完整项目,至于原因以及整个项目框架后边文章我再说明.既然要起一个完整的项目,那么数据仓储访问就必不可少,这篇文章我主要介绍这个新项目(OSS.Core)中我对仓储层的简单思考和实现过程(当前项目还处在搭建阶段),主要集中在以下几个方面: 1. 数据仓储层的需求 2. ORM框架选择 3. OSS.Core仓储层设计实现 4. 调用示例 下边的实现部分中可能需要你对.NET的 泛型,委托,扩展,表达式等有一个基础了解.正是因为这些语言特性,方便我们对操作共性的

大神勿喷,小神默默学. 会了就是不值一提的东西,不会就是绝对的高大上. 最后上传源码.希望能给读者带来一些新的认识及知识. 还没上过头条..各位大神,请点支持一下小弟. 陆续更新.更新到你会为止!! 我不是话唠,我只把重点点出来,细枝末节的不懂的可以留言探讨.这个系列的最后,我会再统一的把大家的问题,列在一篇新的Blog.工作需要规划,写博客也是如此. 需求 ①请保持EF上下文的线程唯一.防止脏临时数据的出现 ②请对程序扩展性做好设计.以后ef框架可能改为Spring框架 ③服务层调用仓储层时.

前言 好多年前,DAL 作为数据库访问层,其实是非常流行的命名方式. 不知道从什么时候开始,仓储层成了新的时尚名词.目前了解到,许多人只要在项目中看见 DAL 就会觉得很 low,但是比较可笑的一点是,多数的仓储层与 DAL 实质在做同样的事情. 本文正要介绍这种比较 low 的方式,来现实通用的仓储层. 参考规范 与其他规范标准一样,仓储层也有相应的规范定义.FreeSql.Repository 参考 abp vnext 代码,定义和实现基础的仓储层(CURD),应该算比较通用的方法吧. IB

前沿 园子里已有挺多博文介绍了EFCore+Mysql/MSSql如何进行使用,但实际开发不会把EF层放在Web层混合起来,需要多个项目配合结构清晰的进行分层工作,本文根据个人实践经验总结将各个项目进行分层,仅供想自己搭建,包含数据仓储以及分页多字段排序. 目录结构 1.实体层(EF)搭建 1.1添加Nuget包 1.2添加实体 1.3构造DbContext 1.4数据迁移生成数据库 2.仓储层搭建 2.1添加Nuget包 2.2添加必要的支持IEnumerable<T>和IQueryable

书接上文,继续搭建我们基于.netCore 的开发框架.首先是我们的项目分层结构. 这个分层结构,是参考张老师的分层结构,但是实际项目中,我没有去实现仓储模型.因为我使用的是EFCore ,最近也一直在想,EFCore 在我们的架构体系中到底扮演着什么样的角色?? 当然,实现仓储层,也有他的好处,如果真的以后要更换ORM框架的时候,不用去更改服务层逻辑,不用直接在仓储里面做更改就可以了.但是对于小项目,可能运行个十年都不会换数据库,不会换ORM的项目,仓储层的意义在哪? 希望对此有自己想法的朋友

回到目录 Lind.DDD项目主要面向敏捷,快速开发,领域驱动等,对于它的分层也是能合并的合并,比之前大叔的框架分层更粗糙一些,或者说更大胆一些,在开发人员使用上,可能会感觉更方便了,更益使用了,这就是大叔开发Lind.DDD框架的目的,让一切变得更简单... Lind.DDD层 主要是公用方法,组件,规约等,如日志组件(Logger),消息组件(Messaging),IOC,AOP,缓存(Caching),异常,请求/响应,用户授权(Authorization),安全校验,领域模型(Domai

前言 简单整理一下仓储层. 正文 在共享层的基础建设类库中: /// <summary> /// 泛型仓储接口 /// </summary> /// <typeparam name="TEntity">实体类型</typeparam> public interface IRepository<TEntity> where TEntity : Entity, IAggregateRoot { IUnitOfWork UnitOf

回到目录 再论Domain与Infrastructure 在面向领域的设计中,领域层(Domain)实现上是位于最底层的,其它层有对它的引用,包括基础设施层(Infrastructure)也是去引用领域层的,我认为,这是对的,事实上,在Domain中会规定如何去进行数据持久化的操作,包括方法名,方法签名等等,而采用哪种架构去实现这种持久化的方法则是Infrastructure层需要做的,这种设计绝对是把领域,业务放在第一位的,完全符合Eric 的DDD. Domain.Core Layer &

我们现在先来看看数据库的生成顺序   居然是 Idal层排在第一,而 web层在第二,model层反而在第三 了   我们需要把 coomon 公用层放在第一,Model层放在第二,接下来是 Idal层,dal层,然后是bll层,最后是 web层,这个顺序怎么调整呢? 点击旁边的依赖项. 分别把每个项目所依赖的项目都勾选上,最后点击确认后,我们看看生成顺序. 这样,当我们生成 web层的时候,会自动从上到下生成 common,model,idal,dal,bll层. 我们对web层进行生成一下,

写在开头 2018年11月的某一天,头脑发热开启了 FreeSql 开源项目之旅,时间一晃已经四年多,当初从舒服区走向一个巨大的坑,回头一看后背一凉.四年时间从无到有,经历了数不清的日夜奋战(有人问我花了多长时间投入,答案:全职x2 + 前两年无休息,以及后面两年的持续投入).今天 FreeSql 已经很强大,感谢第一期.第二期.第N期持续提出建议的网友. FreeSql 现如今已经是一个稳定的版本,主要体现: API 已经确定,不会轻易推翻重作调整,坚持十年不变的原则,让使用者真真正正的不再关

大神勿喷,小神默默学. 会了就是不值一提的东西,不会就是绝对的高大上. 最后上传源码.希望能给读者带来一些新的认识及知识. 还没上过头条..各位大神,请点支持一下小弟. 陆续更新.更新到你会为止!! 我不是话唠,我只把重点点出来,细枝末节的不懂的可以留言探讨.这个系列的最后,我会再统一的把大家的问题,列在一篇新的Blog.工作需要规划,写博客也是如此. 仓储层:待优化 基接口:约束 子接口:实现基接口.进一步约束子仓储中特殊的方法. *基仓储:具体实现,子类继承接口的方法. 这步最难,最重要!

//代码调用由业务层调用,调用方式详见源代码的业务层,升级直接替换TT模板即可,无需覆盖系统using System; using System.Collections.Generic; using System.Data.Entity.Infrastructure; using System.Data.SqlClient; using System.Linq; using System.Linq.Expressions; using System.Text; using System.Thre

前言 1.本文的前提条件:EF上下文是线程唯一,EF版本6.1.3. 2.网上已有相关API的详细介绍,本文更多的是作为我自己的个人学习研究记录. 3.2018-05-31修改DbSession.cs部分严重错误代码! 疑问 用反编译工具翻开DbContext类可以看到EF本身就是一个实现了工作单元的仓储层,每运行一次DbContext.SaveChanges()便提交一次工作单元,那么本文要探究的问题来了: 如何在service层调用多个repository实例时实现工作单元? 上述方法的正确

松耦合.针对抽象编程.不针对实现编程是面向对象设计的原则.依赖注入就是,在一个类的内部,不通过创建对象的实例而能够获得实现了某个公开接口的对象引用.所谓的控制反转也是相同的意思.把依赖的创建转移到了使用这些依赖的类的外部,反转的是依赖的创建.控制反转可以是通过依赖注入和服务定位器模式来实现.依赖注入特别适用于复杂的依赖关系的程序中. 在Asp.net MVC程序中,经常使用仓储模式来分离控制器和数据访问层.有利于进行单元测试和测试驱动开发(TDD). 实现依赖注入可以使控制器和使用的仓储层相互独

返回总目录 自从写这个系列博客之后,发现很多园友还是希望有个直接运行的demo,其实在github上就有官方的demo,我直接把这demo的链接放到这里吧,另外,我分析,这些找不到demo的同学,很可能是不怎么用github,可能的原因就是英文不好.所以还是希望程序员多看看英文文档,一开始看得很慢不要紧,时间久了,速度绝对能上去.因为都是技术性的文章,没有特别难的语法,能让大家退而却步的最多是些生词,这个就要靠大家积累常见的词汇了,一些生僻词的话查一下意思,理解了那句话就可以过了. 跟ABP相关

ABP理论学习之N层架构   返回总目录 自从写这个系列博客之后,发现很多园友还是希望有个直接运行的demo,其实在github上就有官方的demo,我直接把这demo的链接放到这里吧,另外,我分析,这些找不到demo的同学,很可能是不怎么用github,可能的原因就是英文不好.所以还是希望程序员多看看英文文档,一开始看得很慢不要紧,时间久了,速度绝对能上去.因为都是技术性的文章,没有特别难的语法,能让大家退而却步的最多是些生词,这个就要靠大家积累常见的词汇了,一些生僻词的话查一下意思,理解了那

目录 DDD实践:如何用DDD重构中台业务模型? 领域建模:如何用事件风暴构建领域模型? 代码模型(上):如何使用DDD设计微服务代码模型? 代码模型(下):如何保证领域模型与代码模型的一致性? 边界:微服务的各种边界在架构演进中的作用? 视图:如何实现服务和数据在微服务各层的协作? 从后端到前端:微服务后,前端如何设计? 知识点串讲:基于DDD的微服务设计实例 基于DDD的微服务设计实例代码详解 总结(一):微服务设计和拆分要坚持哪些原则? 总结(二):分布式架构关键设计10问 DDD实践:如

写在前面 首先,本篇博文主要包含两个主题: 领域服务中使用仓储 SELECT 某某某(有点晕?请看下面.) 上一篇:Repository 仓储,你的归宿究竟在哪?(二)-这样的应用层代码,你能接受吗? 关于仓储这个系列,很多园友问我:为什么纠结仓储?我觉得需要再次说明下(请不要再"纠结"了),引用上一篇博文中某一段评论的回复: 关于"纠结于仓储"这个问题,其实博文中我就有说明,不是说我纠结或是陷入这个问题,而是我觉得在实践领域驱动设计中,仓储的调用是一个很重要的东西

Repository 仓储 写在前面 首先,本篇博文主要包含两个主题: 领域服务中使用仓储 SELECT 某某某(有点晕?请看下面.) 上一篇:Repository 仓储,你的归宿究竟在哪?(二)-这样的应用层代码,你能接受吗? 关于仓储这个系列,很多园友问我:为什么纠结仓储?我觉得需要再次说明下(请不要再“纠结”了),引用上一篇博文中某一段评论的回复: 关于“纠结于仓储”这个问题,其实博文中我就有说明,不是说我纠结或是陷入这个问题,而是我觉得在实践领域驱动设计中,仓储的调用是一个很重要的东西,