EntityFramework

一、前言 毕业后入职现在的公司快有一个月了，公司主要的产品用的是C/S架构，再加上自己现在还在学习维护很老的delphi项目，还是有很多不情愿的。之前实习时主要是做.NET的B/S架构的项目，主要还是用的那种传统的开发模式，只有一个项目用到了Web API，自己负责后端的接口功能实现。既然现在没办法改变现状，那就先改变自己吧。定了个计划，下班后慢慢的开始学习ASP.NET Core Web API和Vue，准备从前端到后端自己写一个小项目玩玩，毕竟代码这个东西，时间长了是会忘的。 嗯，有点扯远了。这个MVC项目是我的毕业设计，虽然写的比较烂，而且当时为了赶紧写完，代码的冗余程度有点高，但还是希望能给一些准备入门ASP.NET Core MVC的童鞋提供些借鉴吧。代码我放到Github上了，源码地址https://github.com/Lanesra712/Danvic.PSU，欢迎大神们拍砖，指出不足处。 二、项目介绍 毕业论文的课题是一个大学生的一个报名系统，主要是为了完成大学生报名过程中的一些数据维护，当然最后因为实在来不及了，好多都没做。。。项目主要使用到的相关技术如下所示： 项目框架：ASP.NET Core 2.0 MVC ORM：Entity Framework Core（使用Code First） 数据库引擎：MySQL SERVER 5.7 权限验证

在上一篇文章中讲解了如何生成EF的DBFirst模式，接下来讲解如何使用DBFirst模式实现数据库数据的增删改查 一、新增数据 新增一个Student，代码如下： 1 static void Add() 2 { 3 using (StudentSystemEntities dbContext = new StudentSystemEntities()) 4 { 5 // 定义Student对象 6 Student stu = new Student() 7 { 8 StudentName = " 花千骨 " , 9 Sex = " 女 " , 10 Age = 3422 , 11 Major = " 舞蹈专业 " , 12 Email = " 2345678911@qq.com " 13 }; 14 // 将EF执行的SQL语句输出到控制台 15 dbContext.Database.Log += p => Console.WriteLine(p); 16 // 只是内存上面的操作 17 dbContext.Students.Add(stu); 18 // 保存的数据库 19 dbContext.SaveChanges(); 20 Console.WriteLine( " 保存成功 " ); 21 } 22 } 在Main()方法里面调用Add()方法，结果： 查看数据库结果：

一、FluentAPI： 1、基本配置： namespace ConsoleApp14.ModelConfig { public class PersonConfig: EntityTypeConfiguration<Person> { // 继承自EntityTypeConfiguration，并将Person传进来 public PersonConfig() { this .ToTable( " T_Persons " ); } } } public class TestDbContext:DbContext { public TestDbContext(): base ( " name=connstr " ) // name=connstr 表示使用连接字符串中名字为connstr的数据库 { } public DbSet<Person> Persons { get ; set ; } protected override void OnModelCreating(DbModelBuilder modelBuilder) { base .OnModelCreating(modelBuilder); // 用法一：从本程序集中加载所有继承自EntityTypeConfiguration类的配置 modelBuilder.Configurations

在线场景中保存数据 在线场景中保存实体数据是一项相当容易的任务，因为使用的是同一个context,这个context会自动跟踪所有实体发生的更改。 下图说明了在线场景中的CUD（创建，更新，删除）操作。 EF在调用context.SaveChange方法时，根据EntityState进行添加、修改或删除实体实例，并执行INSERT，UPDATE和DELETE语句。在线场景中，context跟踪所有实体的实例，EntityState无论何时创建，修改或删除实体，它都会自动为每个实体设置适当的实例。 1.插入数据 使用DbSet.Add方法将新实体添加到上下文（context），调用context.SaveChanges()方法时在数据库中插入新记录。 using ( var context = new SchoolDBEntities()) { var std = new Student() { FirstName = " Bill " , LastName = " Gates " }; context.Students.Add(std); context.SaveChanges(); } 在上面的示例中，context.Students.Add(std)将新创建的Student实体实例,这个新实例的EntityState 为Added。调用context.SaveChanges(

EF中的持久性场景 使用EF实现实体持久化（保存）到数据库有两种情况：在线场景和离线场景。 1.在线场景 在线场景中，context是同一个上下文实例（从DbContext派生），检索和保存实体都通过同一个context上下文，因此在线场景中的持久化十分简单。 这种方案适用于连接本地数据库或同一网络上的数据库。 优点： 执行速度快。 上下文跟踪所有实体，并在实体发生更改时自动设置适当的状态。 缺点： 上下文保持在线状态，因此与数据库的连接保持打开状态。 利用更多资源。 2.离线场景 离线场景中，使用不同上下文实例进行检索和保存。一个context检索实体后被释放，创建一个新的实体进行保存工作。 离线场景的保存相对复杂，因为新创建的context没有跟踪实体，因此必须在保存实体之前为每个实体设置适当的状态。在上图中，应用程序使用Context 1检索实体图，执行一些CUD（创建，更新，删除）操作。使用Context2保存时，Context2不知道在这个实体图上执行过哪些操作。 离线场景适用于Web应用程序或远程数据库。 优点： 与在线方案相比，使用更少的资源。 没有与数据库的长连接。 缺点： 需要在保存之前为每个实体设置适当的状态。 执行速度比在线方案慢。 EF系列目录链接： Entity Franmework系列教程汇总 来源： oschina 链接： https://my

　　 Entity Framework DBContext 增删改查深度解析 有一段时间没有更新博客了，赶上今天外面下雨，而且没人约球，打算把最近对Entity Framework DBContext使用的心得梳理一下，早些时候在网上简单查过，对于最新版本的EF并没有类似的知识梳理类文章，希望对大家有所帮助。 1. 不要Code first, 也不要DB first 我为什么讨厌Code first和DB first呢？首先Code first是先写代码，数据库完全由代码生成，开发阶段尚可，一旦到了产品发布阶段，如果需要添加字段，我们总不能用 visual studio去生产环境上去更新数据库吧，听起来就很可怕。而且另外的一个问题自动是生成的数据库脚本也不可控，还不如自己提前设计好。DB first也好不了哪去，反向转过来的代码包含很多没有用的文件，而且数据库的更新还要重新走Model生成过程，简直无法理解为什么会有这样的设计。 说了这么多，怎么解决呢？ 数据库和领域模型分开设计，按照对应关系映射字段，使用自定义链接字串，既不使用领域模型生成数据库，也不用数据库生成领域模型，示例代码如下， SQL Code 以 Destinations和TTable表为例： CREATE TABLE [DBO].[Destinations] ( [DestinationId] [ int ]

强类型ID 实体通常是整数，GUID或者string类型，因为数据库直接支持这些类型，但是，如果实体的ID的类型是一样的，比如都是整数的ID，这有可能会出现ID值传错的问题，看下边的示例。 public void AddProductToOrder(int orderId, int productId, int count) { ... } ... // 这个地方，参数传错了 AddProductToOrder(productId, orderId, int count); 上面的代码可以很好地通过检查并编译，但是在运行的时候就出问题了，这是逻辑bug。 幸运的是，可以定义强类型id来解决这个问题，这个想法很简单，为每个实体的ID声明一个特定的类型，现在需要这样写： // 使用强类型ID代替整数ID public void AddProductToOrder(OrderId orderId, ProductId productId, int count) { ... } ... // 这个地方，参数传错了 AddProductToOrder(productId, orderId, int count); 在上面的代码中，我们犯了与第一个示例相同的错误（交换productId和orderId），但是在这种情况下，类型不同，因此编译器会捕获该错误并报告错误,我们仍然需要对其进行修复

【导读】 仓储模式我们已耳熟能详，但当我们将其进行应用时，真的是那么得心应手吗？确定是解放了生产力吗？这到底是怎样的一个存在，确定不是反模式？ 一篇详文我们探讨仓储模式，这里仅我个人的思考，若有更深刻的理解，请在留言中给出 仓储反模式 5年前我在Web APi中使用EntityFramework中写了一个仓储模式，并将其放在我个人github上，此种模式也完全是参考所流行的网传模式，现如今在我看来那是极其错误的仓储模式形式，当时在EntityFramework中有IDbSet接口，然后我们又定义一个IDbContext接口等等，大同小异，接下来我们看看在.NET Core中大多是如何使用的呢？ ???? 定义通用IRepository接口 public interface IRepository<TEntity> where TEntity : class { /// <summary> /// 通过id获得实体 /// </summary> /// <param name="id"></param> /// <returns></returns> TEntity GetById(object id); //其他诸如修改、删除、查询接口 } 当然还有泛型类可能需要基础子基础类等等，这里我们一并忽略 ???? 定义EntityRepository实现IRepository接口

https://docs.microsoft.com/zh-cn/nuget/consume-packages/install-use-packages-visual-studio 通过 Windows 版 Visual Studio 中的 NuGet 包管理器 UI，可轻松安装、卸载和更新项目和解决方案中的 NuGet 包。 若要了解 Visual Studio for Mac 的使用体验，请参阅 在项目中包括 NuGet 包 。 Visual Studio Code 中不包含包管理器 UI。 备注 如果 Visual Studio 2015 中缺少 NuGet 包管理器，请选中“工具”>“扩展和更新...” 并搜索“NuGet 包管理器” 扩展。 如果无法在 Visual Studio 中使用扩展安装程序，请直接从 https://dist.nuget.org/index.html 下载扩展。 从 Visual Studio 2017 开始，NuGet 和 NuGet 包管理器会与任何 .NET 相关的工作负载一起自动安装。 通过在 Visual Studio 安装程序中选择“单个组件”>“代码工具”>“NuGet 包管理器” 选项，可以单独安装它。 查找和安装包 在“解决方案资源管理器”中，右键单击“引用”或某个项目，然后选择“管理 NuGet 包...” 。 “浏览”

　　在开发数据库应用程序的时候，经常会遇到某些表需要添加字段或者修改类型、新增表等需求，而对于EF Code First来说关注的只有实体类，当需求变更时只需要添加新的实体类或者在实体类中添加、删除、修改属性即可。但是修改完成之后要如何将修改同步到数据库中？ 　　Entity Framework提供了Migrations机制来解决这一问题。 　　本文要点： 　　●启用Migrations 　　●通过Add-Migration添加Migration 　　●Update-Database更新数据库 　　●更新模型并添加新的Migration 　　●启动应用时自动将数据库更新至最新版本 　　●关于Automatic Migrations(自动迁移) 启用Migrations 　　在VS中的Package Manager Console窗口中选择默认项目为DbContext存在的项目，并执行命令： 　　 enable-migrations 　　 　　然后项目中将生成Migrations目录和Configuration类型： 　　 　　 　　构造方法：用于对一些Migrations相关的配置，如上代码就是禁用了自动迁移。 　　Seed方法：根据注释可知在迁移后执行，一般用来添加默认数据。Configuration类型可以根据需求进行修改。 　　注：如过出现以下错误，可把命名空间删除修复：