我们经常在项目中使用仓储(Repository)模式,来实现解耦数据访问层与业务层.那在.net core使用EF core又是怎么做的呢? 现在我分享一下我的实现方案: 一.在领域层创建Repository类. 1.首先定义实体接口 . /// <summary> /// Entity接口 /// </summary> /// <typeparam name="TId"></typeparam> public interface IEn

一.前言 最近在学习研究ABP,使用到微软的ORM框架 Entity Framework(后面简称EF),将其基本操作记录下来. 二.程序包管理器控制台 为了能够在控制台中使用命令行来操作EF,需要先安装Microsoft.EntityFrameworkCore.Tools. 安装 Install-Package Microsoft.EntityFrameworkCore.Tools 更新 通过该指令就可以升级Microsoft.EntityFrameworkCore.Tools Update-

接着写一下 上一章提到的 BaseRepositoryRedis.cs 先说说题外话:由于公司希望用到缓存来提高访问速度.那么我理所当然的想到redis. 这个无可厚非.可是当时我们的项目已经开发的差不多的了.... 我懒,也不可能到bll或者 dal去增加缓存代码. 于是我就想到了,既然我们的dal可以继承自BaseRepository.cs 那么一样也可以继承BaseRepositoryRedis.cs 只需要coder自己来选择是否需要缓存,需要的继承BaseRepositoryRedis

构建一个仓储模式. Model 大家自己创建就行了,上个图,就不多说了(我是code first) IDAL namespace IDAL { public interface IBaseRepository<T> { /// <summary> /// 添加 /// </summary> /// <param name="entity">数据实体</param> /// <returns>添加后的数据实体<

前言 其实就是一个简单依赖注入的三层架构.记录一下,大佬们就不用看下去了.重点在最后面,可以直接拖到底去看. 正文 1.贴代码 1.整体的一个结构.大佬们应该一眼就看明白了. 2.MySqlContext using Model; using Microsoft.EntityFrameworkCore; namespace DbFactory { public class MySqlContext : DbContext { public MySqlContext(DbContextOption

1.点击“工具”->“NuGet包管理器”->“程序包管理器控制台” 分别安装以下几个包 Mysql 版本: Install-Package MySql.Data.EntityFrameworkCore -Pre Install-Package Pomelo.EntityFrameworkCore.MySql Install-Package Microsoft.EntityFrameworkCore.Tools Install-Package Microsoft.VisualStudio.We

回到目录 Lind.DDD.Repositories.EF以下简称Repositories.EF,之所以把它从Lind.DDD中拿出来,完全出于可插拔的考虑,让大家都能休会到IoC的魅力,用到哪种方法持久化,就将那个DLL放到应用程序中,完全不需要把所有持久化方式耦合到一个项目里,这也是遵循了OCP的原则,对扩展是开放的,即你可以添加其它的持久化方式,在新的项目里:而不要在原有的项目中进行代码的修改． Repositories.EF做为数据持久化的一种方式,它直接继承了Lind.DDD.IRep

一.前言 从去年已经接触领域驱动设计(Domain-Driven Design)了,当时就想自己搭建一个DDD框架,所以当时看了很多DDD方面的书,例如领域驱动模式与实战,领域驱动设计:软件核心复杂性应对之道和领域驱动设计C# 2008实现等书,由于当时只是看看而已,并没有在自己代码中进行实现,只是初步了解一些DDD分层的思想和一些基本概念,例如实体,聚合根.仓储等概念,今年有机会可以去试试面试一个架构岗位的时候,深受打击,当面试官问起是否在项目中使用过DDD思想来架构项目时,我说没有,只是了解

最近看了NopCommerce源码,用core学习着写了一个项目,修改的地方记录下.项目地址 NopCommerce框架出来好久了.18年的第一季度 懒加载出来后也会全部移动到.net core.那么就更好玩了.   项目内容 模仿部分 分层模式 引擎机制 DI容器 EF 仓储模式 Mapping 部分修改 .net core 重写类库 EFcore mysql 动态加载dbset 当然NopCommerce还包含很多特技:Plugin,Seo,订阅发布,theme切换等等.这些后期再维护进去.

前言 不知道大家是否和我有同样的问题: 一般在数据库的设计阶段,会制定一些默认的规则,其中有一条硬性规定就是一定不要对任何表中的数据执行delete硬删除操作,因为每条数据对我们来说都是有用的,并且是值得分析的. 所以我们一般会在每张表中加一个"是否删除IsDeleted"或者"是否有效IsValid"的字段,来标识这条数据的状态是否可用! 那么疑问来了,在写SQL或者Linq的时候我们到底是要加上这个条件还是忽略这个条件呢?答案当然是根据实际业务需求和情况来决定.

在上篇教程中,我们在WebApi项目中集成了Miniprofiler,本篇文章中,将继续集成Miniprofiler EF6,以实时监测分析EF的执行语句.执行效率等.Miniprofiler会针对EF调用中存在的低效执行给出提示. Install-Package MiniProfiler.EF6 ABP安装在Web项目中. 在dbcontext初始化之前执行代码MiniProfilerEF6.Initialize(); ABP在global.asax的Application_Start()方法

最近看了NopCommerce源码,用core学习着写了一个项目,修改的地方记录下.项目地址 NopCommerce框架出来好久了.18年的第一季度 懒加载出来后也会全部移动到.net core.那么就更好玩了.   项目内容 模仿部分 分层模式 引擎机制 DI容器 EF 仓储模式 Mapping 部分修改 .net core 重写类库 EFcore mysql 动态加载dbset 当然NopCommerce还包含很多特技:Plugin,Seo,订阅发布,theme切换等等.这些后期再维护进去.

目前在vscode上用netcore + ef core,在用dbfirst的方式生成模型和context上下文一直没有找到方法,之前在vs2017中,的nuget管理控制台输入命令: Scaffold-DbContext "Server=.\TestDB;Database=TestDbName;Trusted_Connection=True;MultipleActiveResultSets=true;" Microsoft.EntityFrameworkCore.SqlServer

本文将在技术层面挑战园子里的权威大牛们,言语不敬之处敬请包涵.本文旨为技术交流,欢迎拍砖. 园子里面分享和推荐Entity Framework(以下简称EF)的Repository(仓储)设计模式的文章真不少,其中还有很多大牛很详细描述怎么去实现.但是这些文章真是害人不浅.我现在想问问这些大牛们,你们现在的项目真的还在这样用吗? 下面是在找找看里面随便挑的几篇,如果你从未了解过EF Repository,你可以看看: 分享基于Entity Framework的Repository模式设计(附源码

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

p { display: block; margin: 3px 0 0 0; } --> .NET架构基础方法—DataTableToList通用方法   我们经常需要将从数据库中所读取的数据以DataTable类型返回,也经常需要遍历DataTable转换为List<T>.我们也经常需要为每一个DataTable转换为List单独编写适合他们数据库架构地方法.下面上代码: public static class DataTableTools<T> where T : cla

首先这里发一下结构图,因为是重写的,但是代码都是一样所有如下: 这里我先说一下看了大部分的DDD文章都是采用的WCF做服务,这里呢我用的是webapi做服务,WCF和WEBAPI的区别可以去百度下. 好了.现在我们看下automapper的具体实现. 因为automapper又一个Profile类,而我们自己写的类去继承这个类,所有如下图: 上图是创建映射关系,下面就去添加映射 这些做完了 我们现在需要使用 这里的dto类型是CostomDTO 也就是数据传输对象. 下面我们来看下工作单元,下面

关于她 LindAgile是大叔在这两年里的新宠儿,它主推模块化,插件化,敏捷化,主要于LindAgile基础项目,LindAgile.Http项目,LindAgile.Modules项目和几个扩展模块项目组成,那几个扩展模块主要体现的AOP的特性,需要哪些模块,就在应用程序里注册哪些. LindAgile公用项目 LindAgile基础项目 实体Domain 实体跟踪器EntityTracks 数据传输对象DTO 文件缓存FileCache 面向切面LindAspects 面向插件LindPl

写这篇文章的心情:激动 Microsoft.Extensions.DependencyInjection在github上同样是开源的,它在dotnetcore里被广泛的使用,比起之前的autofac,unity来说,它可以说是个包裹,或者叫适配器,它自己提供了默认的DI实现,同时也支持第三方的IOC容器,在这段时间里使用了它,就想,这东西为什么被在dotnetcore里大放异彩?为什么会全程使用它?从程序的开始到程序启动起来,你可以发现它无处不在,在框架里是这样,在业务层同时也是这样. 聊聊Mi

贴一个EF6 CodeFirst模式结合MVC5和Autofac(泛型注册)的一个入门实例 网上类似的例子实在太少,最近自己也有用到这一块的知识,总结了一下,不要让后人踩了自己踩过的坑. 1:新建三个项目,Web(MVC).EntityFramework类库(EF框架).Core类库(核心框架),nuget EntityFramework 2:建立简单对象:书籍(Book)Model,继承主键为Int的基类 ①:接口 namespace:Core.Domain.Interface /// <su

前几天,有园友私下问我,博客中的AccountDemo后端架构为什么是那样的,是不是分层太多太冗余,故这里简单介绍下.先看解决方案工程截图: 每个工程的含义,见https://www.cnblogs.com/guokun/p/7082987.html.运行时,请求处理流程,这里再贴出来: 这里,园友主要不解的是,为什么会有两个接口层,Account.Repository.Contract和Account.Service.Contract,是不是太多了.最近几年,在后端架构中,出现了一种称之为六边