<10分钟就能学会.NET Core配置>里详细介绍了.NET Core配置的用法,另外我还开源了自定义的配置Provider:EF配置Provider和Yaml配置Provider.本文先来聊聊EF配置Provider的实现,其中会涉及到EntityFramework Core的知识,不熟悉也没关系,且听我慢慢讲来. 配置执行流程 在使用配置的时候都是先new ConfigurationBuilder(),最后调用Build()方法赋值给Configuration属性.那我们就从这个Buil

下面用一篇文章来完成这些事情 多租户系统的设计单纯的来说业务,一套Saas多租户的系统,面临很多业务复杂性,不同的租户存在不同的业务需求,大部分相同的表结构,那么如何使用EFCore来完成这样的设计呢?满足不同需求的数据库结构迁移 这里我准备设计一套中间件来完成大部分分库分表的工作,然后可以通过自定义的Migration 数据库文件来迁移构建不同的租户数据库和表,抛开业务处理不谈,单纯提供给业务处理扩展为前提的设计,姑且把这个中间件命名为: EasySharding 原理:数据库Migation

问题引出 ASP.NET Core 默认将 Web.config移除了,将配置文件统一放在了 xxx.json 格式的文件中. 有Web.config时,我们需要读到配置文件时,一般是这样的: var value1= ConfigurationManager.ConnectionStrings["connStr"].ConnectionString; 这个ConfigurationManager是在System.Configuration 命名空间下的. 很不幸,默认情况下这个方法也不

在使用.NET CORE 进行 Web 开发的时候会考虑到使用不同数据库的情况,并且在每种数据库建立表结构的时候会采用不同的命名规则.之前的解决方法是使用 [ColumnAttribute] 或者 [TableAttribute] 这种特性来显式标注不同的列名. [Table("bas_stock_address")] public class BasStockAddress : FullAuditedEntity<int, User> { /// <summary&

1.背景 去年时候,写过一篇<Vue2.0 + Element-UI + WebAPI实践:简易个人记账系统>,采用Asp.net Web API + Element-UI.当时主要是为了练手新学的Vue及基于Vue的PC端前端框架Element-UI,所以文章重点放在了Element-UI上.最近,从鹏城回江城工作已三月有余,人算安顿,项目也行将上线,算是闲下来了,便想着实践下之前跟进的.net core,刚好把之前练手系统的后端给重构掉,于是,便有了此文. 2.技术栈 Asp.net co

EFCore中的约定简单来说就是规则,CodeFirst基于模型的约定来映射表结构.除此之外还有Fluent API.Data Annotations(数据注释) 可以帮助我们进一步配置模型. 按照这三者的优先级高低排序分别是:Fluent API.Data Annotations(数据注释).约定. 1.约定 public class Person { public int ID { get; set; } public int Age { get; set; } public bool St

Java Spring Boot VS .NetCore (一)来一个简单的 Hello World Java Spring Boot VS .NetCore (二)实现一个过滤器Filter Java Spring Boot VS .NetCore (三)Ioc容器处理 Java Spring Boot VS .NetCore (四)数据库操作 Spring Data JPA vs EFCore Java Spring Boot VS .NetCore (五)MyBatis vs EFCore

Java Spring Boot VS .NetCore (一)来一个简单的 Hello World Java Spring Boot VS .NetCore (二)实现一个过滤器Filter Java Spring Boot VS .NetCore (三)Ioc容器处理 Java Spring Boot VS .NetCore (四)数据库操作 Spring Data JPA vs EFCore Java Spring Boot VS .NetCore (五)MyBatis vs EFCore

Java Spring Boot VS .NetCore (一)来一个简单的 Hello World Java Spring Boot VS .NetCore (二)实现一个过滤器Filter Java Spring Boot VS .NetCore (三)Ioc容器处理 Java Spring Boot VS .NetCore (四)数据库操作 Spring Data JPA vs EFCore Java Spring Boot VS .NetCore (五)MyBatis vs EFCore

EF常用处理关联加载的方式有3中:延迟加载(Lazy Loading).贪婪加载 (Eager Loading)以及显示加载. 一.EF Core  1.1 1.当前的版本,还不支持延迟加载(Lazy Loading),不将来是否支持 2.目前支持贪婪加载:使用Include加载 关联表 的数据,这种方式 使用一条Join的 Sql语句进行查询. 3. 贪婪加载的优势在于仅执行1次SQL查询即返回所需要的结果.但使用JOIN查询在数据库记录条数较多时,多条简单的SQL查询往往比一条复杂的JOIN

EF6中可以直接根据代码模型生成数据库Database.SetInitializer即可 在EFCore中如何实现呢? 这项功能放在了DatabaseFacade对象中,传入数据库上下文对象实例化到一个DatabaseFacade对象 可以看到DatabaseFacade有几个方法: 获取所有迁移的migraion数据:GetMigrations 获取待迁移的migration数据 :GetPendingMigrations 获取已经操作的migration数据:GetAppliedMigrat

如何从40亿整数中找到不存在的一个 前言 给定一个最多包含40亿个随机排列的32位的顺序整数的顺序文件,找出一个不在文件中的32位整数.(在文件中至少确实一个这样的数-为什么?).在具有足够内存的情况下,如何解决该问题?如果有几个外部的“临时”文件可用,但是仅有几百字节的内存,又该如何解决该问题? 分析 这仍然是<编程珠玑>中的一个问题.前面我们曾经提到过<位图法>,我们使用位图法解决了这个问题.32位整型最多有4294967296个整数,而很显然40亿个数中必然会至少缺一个.我们

EFCore在DDD中的使用 在DDD中,我们对聚合根的操作都会通过仓储去获取聚合实例. 因为聚合根中可能会含有实体属性,值对象属性,并且,在DDD中,我们所设计的领域模型都是充血模型.所以,在对聚合根的持久化中,最方便的还是Mangodb这种KEY-VALUE存储的NOSQL. 不过,关系型数据库通过EF也能方便的解决复杂模型的数据库映射. 本文使用EFCore,部分API不适用于EF:本文不谈DDD. 以下引出几个知识点: backing field releation lazy load

EFCore扩展Select方法(根据实体定制查询语句)  通常用操作数据库的时候查询返回的字段是跟 我们的定义的实体是不一致的,所以往往针对UI或者接口层创建大量的Model, 而且需要手动对应字段,非常繁琐. 本文将通过表达式树解决这些重复的过程. 先贴上实现代码 Queryable 类中 的扩展方法  Select<TSource, TResult>(this IQueryable<TSource> source, Expression<Func<TSource,

准备工作 本篇文章基于上篇基础上进行的,请先了解此篇  surging+CentOS7+docker+rancher2.0 菜鸟部署运行笔记 开发环境  Visual Studio 2017 15.5 数据库 sql server 2012 运行环境  虚拟机CentOS 7+Docker+Rancher 2.0+Consul+RabbmitMQ surging项目下载地址  https://github.com/dotnetcore/surging demo下载地址 https://githu

abp(net core)+easyui+efcore仓储系统目录 abp(net core)+easyui+efcore仓储系统——ABP总体介绍(一) abp(net core)+easyui+efcore仓储系统——解决方案介绍(二) abp(net core)+easyui+efcore仓储系统——领域层创建实体(三) 在上一篇文章中我们创建了Module实体并在数据库中生成了数据表,在这一文章中我们介绍如何来对数据库进行操作. 一.先来介绍下仓储 仓储(Repository): 仓储用

abp(net core)+easyui+efcore实现仓储管理系统目录 abp(net core)+easyui+efcore实现仓储管理系统——ABP总体介绍(一) abp(net core)+easyui+efcore实现仓储管理系统——解决方案介绍(二) abp(net core)+easyui+efcore实现仓储管理系统——领域层创建实体(三) abp(net core)+easyui+efcore实现仓储管理系统——定义仓储并实现 (四) abp(net core)+easyui

系统目录 abp(net core)+easyui+efcore实现仓储管理系统——ABP总体介绍(一) abp(net core)+easyui+efcore实现仓储管理系统——解决方案介绍(二) abp(net core)+easyui+efcore实现仓储管理系统——领域层创建实体(三) abp(net core)+easyui+efcore实现仓储管理系统——定义仓储并实现 (四) abp(net core)+easyui+efcore实现仓储管理系统——创建应用服务(五) abp(ne

比如项目内已经使用了其它 orm,如 efcore,这样意味着实体中可能存在 [Key],但它与 FreeSql [Column(IsPrimary = true] 不同. Q: FreeSql 实体特性为啥这么别扭? A: 为了考虑一致性用法,全部封装在 ColumnAttribute 下,这样用户使用起来,不用到处 using 或者 回忆特性应该用哪个名字,如自增 [Column(IsIdentity = true)] 即可. FreeSql 提供 AOP 自定义特性功能,实现与多个 orm

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

故事背景 最近在把自己的一个老项目从Framework迁移到.Net Core 3.0,数据访问这块选择的是EFCore+Mysql.使用EF的话不可避免要和DbContext打交道,在Core中的常规用法一般是:创建一个XXXContext类继承自DbContext,实现一个拥有DbContextOptions参数的构造器,在启动类StartUp中的ConfigureServices方法里调用IServiceCollection的扩展方法AddDbContext,把上下文注入到DI容器中,然后