整理一下目前在用的EFCore 记得好像是因为懒得写sql,于是开始试着用EF 先根据数据库生成一个好东西,嗯 Scaffold-DbContext "Data Source=localhost;Initial Catalog=dbname;Persist Security Info=True;User ID=admin;Password=admin;Pooling=true;Max Pool Size=512; Min Pool Size=5;" Microsoft.EntityFr

首先 介绍 Scaffold-DbContext "Server=.;database=sdd;User Id=sa;Password=123456;" Microsoft.EntityFrameworkCore.SqlServer -OutputDir building 网上 很多生成 命名是下面这个: Scaffold-DbContext "Server=.;database=test1;Trusted_Connection=True;" Microsoft.E

[ASP.NET Core]EF Core - “影子属性”   有朋友说老周近来博客更新较慢,确实有些慢,因为有些 bug 要研究,另外就是老周把部分内容转到直播上面,所以写博客的内容减少了一点. 老周觉得,视频直播可能会好一些,虽然我的水平一般,不过直播时,老周可以现场演示,可能会比看博客效果要好(因为现场演示,有时候会有失误,没办法,水平有限).还有一个,就是.NET 的资料其实很多,毕竟也发展了十几年了,有些东西如果别人都写过了,那我也不好意思重复了..NET Core 尽管是跨平台版本

C# 嵌入dll   在很多时候我们在生成C#exe文件时,如果在工程里调用了dll文件时,那么如果不加以处理的话在生成的exe文件运行时需要连同这个dll一起转移,相比于一个单独干净的exe,这种形式总归让人不爽,那么有办法让生成的软件中直接就包含这个dll文件吗,这样就可以不用dll跟着exe走了,避免单独不能运行的情况. 答案是有的! 在工程项目目录下找到Resources.resx文件并点击,然后按下面操作,添加资源,将你要加入的dll添加进来. 操作完成后,就会在下面的内容框里看到你添

前言: 在日常开发中,应用程序的性能是我们需要关注的一个重点问题.当然我们有很多工具来分析程序性能:如:Zipkin等:但这些过于复杂,需要单独搭建. MiniProfiler就是一款简单,但功能强大的应用新能分析工具:可以帮助我们定位:SQL性能问题.响应慢等问题. 本篇文章将介绍MiniProfiler在Asp.Net Core中如何使用 一.MiniProfiler介绍 MiniProfiler是一款针对.NET, Ruby, Go and Node.js的性能分析的轻量级程序.可以对一个

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

原文地址:https://www.cnblogs.com/lwqlun/p/10576443.html 作者:Lamond Lu 源代码:https://github.com/lamondlu/EFCoreFindSample 背景介绍 当我们在工作单元(UnitOfWork)中使用EF/EF Core的时候,为了要保持事务,一个用户操作只能调用一次SaveChange方法,但是有时候一个用户操作需要调用多个Repository,并且他们操作的实体是关联的.这时候在一个Repository中获取

ASP.NET Core中使用GraphQL ASP.NET Core中使用GraphQL - 第一章 Hello World ASP.NET Core中使用GraphQL - 第二章 中间件 ASP.NET Core中使用GraphQL - 第三章 依赖注入 ASP.NET Core中使用GraphQL - 第四章 GrahpiQL ASP.NET Core中使用GraphQL - 第五章 字段, 参数, 变量 本篇中我将演示如何配置持久化仓储,这里原文中是使用的Postgres, 这里我改用

在做一个小的Demo中,在一个界面上两次调用视图组件,并且在视图组件中都调用了数据库查询,结果发现,一直报错,将两个视图组件的调用分离,单独进行,却又是正常的,寻找一番,发现是配置依赖注入服务时,对于服务的生命周期没有配置得当导致,特此做一次实验来认识三者之间(甚至是四者之间的用法及区别). 本文demo地址(具体见WebApi控制器中):https://gitee.com/530521314/koInstance.git 一.服务的生命周期 在Asp.Net Core中,内置容器负责管理服务的

Paul Hiles: 3 ways to avoid an anemic domain model in EF Core 1.引言 在使用ORM中(比如Entity Framework)贫血领域模型十分常见 .本篇文章将先探讨贫血模型的问题,再去探究在EF Core中使用Code First时如何使用简单的方法来避免贫血模型. 2.什么是贫血模型 在对领域建模后,输出一系列类中仅包含一些简单属性声明而不包含业务逻辑的模型,就属于贫血模型.当使用Entity Framework时,它们不仅仅是简

EF 6.X中的多对多映射是直接使用HasMany-HasMany来做的.但是到了EF Core中,不再直接支持这种方式了,可以是可以使用,但是不推荐,具体使用可以参考<你必须掌握的EntityFramework 6.X与Core 2.0>一文.在这里我就详细的说下如何在EF core下实现.首先就是实体类的建立: public class Post { public int PostId { get; set; } public string Title { get; set; } publ

一.目前EF Core的版本为V2.1 相比较EF Core v1.0 目前已经增加了不少功能. EF Core除了常用的增删改模型操作,Sql语句在不少项目中是不能避免的. 在EF Core中上下文,可以返货DbConnection ,执行sql语句.这是最底层的操作方式,代码写起来还是挺多的. 初次之外 EF Core中还支持 FromSql,ExecuteSqlCommand 连个方法,用于更方便的执行Sql语句. 另外,目前版本的EF Core 不支持SqlQuery,但是我们可以自己扩

我们知道,在EF Core中DbContext用完后要记得调用Dispose方法释放资源.但是其实DbContext可以多次调用Dispose方法,虽然只有第一次Dispose会起作用,但是DbContext多次调用Dispose方法并不会报错. 我们看看下面的示例代码,可以看到我们调用了DbContext.Dispose三次,加上using代码块一共四次,但是代码并不会报错: string connectionString = "Server=localhost;User Id=sa;Pass

原文地址:http://www.entityframeworktutorial.net/code-first/dataannotation-in-code-first.aspx EF 6 Code-First系列文章目录: 1 翻译系列:什么是Code First(EF 6 Code First 系列) 2.翻译系列:为EF Code-First设置开发环境(EF 6 Code-First系列) 3.翻译系列:EF Code-First 示例(EF 6 Code-First系列) 4.翻译系列:

原文链接:http://www.entityframeworktutorial.net/code-first/notmapped-dataannotations-attribute-in-code-first.aspx EF 6 Code-First系列文章目录: 1 翻译系列:什么是Code First(EF 6 Code First 系列) 2.翻译系列:为EF Code-First设置开发环境(EF 6 Code-First系列) 3.翻译系列:EF Code-First 示例(EF 6

我们来看看下面的代码,这个代码是一个INNER JOIN的EF Core查询,其中用SubCategory表INNER JOIN了SubCategoryLanguage表,但是我们需要在SubCategoryLanguage表上只查询出其DataStatus等于1的行,所以需要用到子查询: ) .Join(dbContext.SubCategoryLanguage.Where(e => e.DataStatus == ), sc => sc.SubCategoryCode, sl =>

EF Core中: 如果调用Queryable.Count等聚合方法,不会导致DbContext跟踪(track)任何实体. 此外调用Queryable.Join方法返回的匿名类型也不会被DbContext所跟踪(实测调用Queryable.Join方法返回EF Core中的实体类型也不会被DbContext所跟踪). Queryable.Count等聚合方法和Queryable.Join方法返回的结果不会被跟踪,原因是因为这两种方法返回的结果类型并没有被DbContext的OnModelCre

使用EF Core时,如果多次从数据库中查询一个表的同一行数据,DbContext中跟踪(track)的实体到底有几个呢?我们下面就分情况讨论下. 数据库 首先我们的数据库中有一个Person表,其建表脚本如下: CREATE TABLE [dbo].[Person]( ,) NOT NULL, ) NULL, [Age] [int] NULL, [CreateTime] [datetime] NULL, CONSTRAINT [PK_Person] PRIMARY KEY CLUSTERED

数据库 假设现在我们在SQL Server数据库中有下面两张表: Person表,代表的是一个人: CREATE TABLE [dbo].[Person]( ,) NOT NULL, ) NULL, ) NULL, [Age] [int] NULL, CONSTRAINT [PK_Person] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY

我们在开发系统的时候,经常会遇到这种需求数据库表中的行被更新时需要自动更新某些列. 数据库 比如下面的Person表有一列UpdateTime,这列数据要求在行被更新后自动更新为系统的当前时间. Person表: CREATE TABLE [dbo].[Person]( ,) NOT NULL, ) NULL, [Age] [int] NULL, [CreateTime] [datetime] NULL, [UpdateTime] [datetime] NULL, CONSTRAINT [PK_

假设在数据库中有两个表:Person表和Book表,Person和Book是一对多关系 Person表数据: Book表数据: 可以看到数据库Book表中所有的数据都属于Person表中"F"这个人 Person表,下面的Person类是该表在EF Core中的实体类型: public partial class Person { public Person() { Book = new HashSet<Book>(); } public int Id { get; set