别跟我谈EF抵抗并发，敢问你到底会不会用EntityFramework
| 有些人号称是对EntityFramwork非常了解，认为不就是增、删、该、查么，但是有的时候用出了问题就开始自我开解，我这么用没有任何问题啊，我们都知道在EF 6.x中确实有很多坑，这个时候就借这个缘由洗白了，这不是我的锅，结果EF背上了无名之锅，妄名之冤。是的，您们没有说错，EF 6.x是有很多坑，您避开这些坑不就得了，我只能说这些人太浮于表面不了解基本原理就妄下结论，你到底会不会用EntityFramework啊。好了来，免说我纸上谈兵，我来举两个具体例子，您们看你到底会不会用。 EntityFramework 6.x查询static void Main(string[] args) { using (var ctx = new EfDbContext()) { ctx.Database.Log = Console.WriteLine;
var code = "Jeffcky"; var order = ctx.Orders.FirstOrDefault(d => d.Code == code); }; Console.ReadKey(); } 这样的例子用过EF 6.x的童鞋估计用烂了吧，然后查询出来的结果让我们也非常满意至少是达到了我们的预期，我们来看看生成的SQL语句。
请问用EF的您们发现什么没有，在WHERE查询条件加上了一堆没有用的东西，我只是查询Code等于Jeffcky的实体数据，从生成的SQL来看可查询Code等于Jeffcky的也可查询Code等于空的数据，要是我们如下查询，生成如上SQL语句我觉得才是我们所预期的对不对。 using (var ctx = new EfDbContext()) { ctx.Database.Log = Console.WriteLine;
var code = "Jeffcky"; var orders = ctx.Orders.Where(d => d.Code == null || d.Code == code).ToList();
}; 如果您真的会那么一点点用EntityFramework，那么请至少了解背后生成的SQL语句吧，这是其中之一，那要是我们直接使用值查询呢，您们觉得是否和利用参数生成的SQL语句是一样的呢？
using (var ctx = new EfDbContext()) { ctx.Database.Log = Console.WriteLine;
var order = ctx.Orders.FirstOrDefault(d => d.Code == "Jeffcky");
};
出乎意料吧，利用值查询在WHERE条件上没有过多的条件过滤，而利用参数查询则是生成过多的条件筛选，到这里是不是就到此为止了呢，如果您们对于参数查询不想生成对空值的过滤，我们在上下文构造函数中可关闭这种所谓【语义可空】判断，如下：
public class EfDbContext : DbContext { public EfDbContext() : base("name=ConnectionString") { Configuration.UseDatabaseNullSemantics = true; } }
在EF 6.x中对于查询默认情况下会进行【语义可空】筛选，通过如上分析，不知您们是否知道如上的配置呢。 EntityFramework 6.x更新EF 6.x更新操作又是用熟透了吧，在EF中没有Update方法，而在EF Core中存在Update和UpdateRange方法，您们是否觉得更新又是如此之简单呢？我们下面来首先看一个例子，看看您们是否真的会用。
static Customer GetCustomer() { var customer = new Customer() { Id = 2, CreatedTime = DateTime.Now, ModifiedTime = DateTime.Now, Email = "2752154844@qq.com", Name = "Jeffcky1" }; return customer; } 如上实体如我们请求传到后台需要修改的实体（假设该实体在数据库中存在哈），这里我们进行写死模拟。接下来我们来进行如下查询，您们思考一下是否能正常更新呢？
using (var ctx = new EfDbContext()) { var customer = GetCustomer(); var dataBaseCustomer = ctx.Customers.FirstOrDefault(d => d.Id == customer.Id); if (dataBaseCustomer != null) { ctx.Customers.Attach(customer); ctx.Entry(customer).State = EntityState.Modified; if (ctx.SaveChanges() > 0) { Console.WriteLine("更新成功"); } else { Console.WriteLine("更新失败"); } }
}; 首先我们根据传过来的实体主键去数据库中查询是否存在，若存在则将传过来的实体附加到上下文中（因为此时请求过来的实体还未被跟踪），然后将其状态修改为已被修改，最后提交，解释的是不是非常合情合理且合法，那是不是就打印更新成功了呢？
看到上述错误想必有部分童鞋一下子就明白问题出在哪里，当我们根据传过来的实体主键去数据库查询，此时在数据库中存在就已被上下文所跟踪，然后我们又去附加已传过来的实体且修改状态，当然会出错因为在上下文已存在相同的对象，此时必然会产生已存在主键冲突。有的童鞋想了直接将传过来的实体状态修改为已修改不就得了么，如下：
using (var ctx = new EfDbContext()) { var customer = GetCustomer(); ctx.Entry(customer).State = EntityState.Modified; if (ctx.SaveChanges() > 0) { Console.WriteLine("更新成功"); } else { Console.WriteLine("更新失败"); } };
如此肯定能更新成功了，我想都不会这么干吧，要是客户端进行传过来的主键在数据库中不存在呢（至少我们得保证数据是已存在才修改），此时进行如上操作将抛出如下异常。
此时为了解决这样的问题最简单的方法之一则是在查询实体是否存在时直接通过AsNoTracking方法使其不能被上下文所跟踪，这样就不会出现主键冲突的问题。 var dataBaseCustomer = ctx.Customers .AsNoTracking() .FirstOrDefault(d => d.Id == customer.Id);
我们继续往下探讨 ，此时我们将数据库Email修改为可空（映射也要对应为可空，否则抛出验证不通过的异常，你懂的），如下图：
然后将前台传过来的实体进行如下修改，不修改Email，我们注释掉。
static Customer GetCustomer() { var customer = new Customer() { Id = 2, CreatedTime = DateTime.Now, ModifiedTime = DateTime.Now, //Email = "2752154844@qq.com", Name = "Jeffcky1" }; return customer; } 我们接着再来进行如下查询试试看。
using (var ctx = new EfDbContext()) { var customer = GetCustomer(); var dataBaseCustomer = ctx.Customers .AsNoTracking() .FirstOrDefault(d => d.Id == customer.Id); if (dataBaseCustomer != null) { ctx.Customers.Attach(customer); ctx.Entry(customer).State = EntityState.Modified; if (ctx.SaveChanges() > 0) { Console.WriteLine("更新成功"); } else { Console.WriteLine("更新失败"); } }
};
按 Ctrl+C 复制代码
此时Email为可空，因为我们设置实体状态为Modified，此时将对实体进行全盘更新，所以对于设置实体状态为Modified是针对所有列更新，要是我们只想更新指定列，那这个就不好使了，此时我们可通过Entry().Property()...来手动更新指定列，比如如下：
using (var ctx = new EfDbContext()) { var customer = GetCustomer(); var dataBaseCustomer = ctx.Customers .AsNoTracking() .FirstOrDefault(d => d.Id == customer.Id); if (dataBaseCustomer != null) { ctx.Customers.Attach(customer); ctx.Entry(customer).Property(p => p.Name).IsModified = true; ctx.Entry(customer).Property(p => p.Email).IsModified = true; if (ctx.SaveChanges() > 0) { Console.WriteLine("更新成功"); } else { Console.WriteLine("更新失败"); } }
};
using (var ctx = new EfDbContext()) { var customer = GetCustomer(); var dataBaseCustomer = ctx.Customers .FirstOrDefault(d => d.Id == customer.Id); if (dataBaseCustomer != null) { dataBaseCustomer.CreatedTime = customer.CreatedTime; dataBaseCustomer.ModifiedTime = customer.ModifiedTime; dataBaseCustomer.Email = customer.Email; dataBaseCustomer.Name = customer.Name; if (ctx.SaveChanges() > 0) { Console.WriteLine("更新成功"); } else { Console.WriteLine("更新失败"); } }
}; 如上也能更新成功而不用将查询出来的实体未跟踪，然后将前台传过来的实体进行附加以及修改状态，下面我们删除数据库中创建时间和修改时间列，此时我们保持数据库中数据和从前台传过来的数据一模一样，如下：
static Customer GetCustomer() { var customer = new Customer() { Id = 2, Email = "2752154844@qq.com", Name = "Jeffcky1" }; return customer; }
接下来我们再来进行如下赋值修改，你会发现此时更新失败的：
using (var ctx = new EfDbContext()) { var customer = GetCustomer(); var dataBaseCustomer = ctx.Customers .FirstOrDefault(d => d.Id == customer.Id); if (dataBaseCustomer != null) { dataBaseCustomer.Email = customer.Email; dataBaseCustomer.Name = customer.Name; if (ctx.SaveChanges() > 0) { Console.WriteLine("更新成功"); } else { Console.WriteLine("更新失败"); } }
};
这是为何呢？因为数据库数据和前台传过来的数据一模一样，但是不会进行更新，毫无疑问EF这样处理是明智且正确的，无需多此一举更新，那我们怎么知道是否有不一样的数据进行更新操作呢，换句话说EF怎样知道数据未发生改变就不更新呢？我们可以用上下文属性中的ChangeTacker中的HasChanges方法，如果上下文知道数据未发生改变，那么直接返回成功，如下：
using (var ctx = new EfDbContext()) { var customer = GetCustomer(); var dataBaseCustomer = ctx.Customers .FirstOrDefault(d => d.Id == customer.Id); if (dataBaseCustomer != null) { dataBaseCustomer.Email = customer.Email; dataBaseCustomer.Name = customer.Name; if (!ctx.ChangeTracker.HasChanges()) { Console.WriteLine("更新成功"); return; } if (ctx.SaveChanges() > 0) { Console.WriteLine("更新成功"); } else { Console.WriteLine("更新失败"); } }
}; 好了到此为止我们已经看到关于更新已经有了三种方式，别着急还有最后一种，通过Entry().CurrentValues.SetValues()方式，这种方式也是指定更新，将当前实体的值设置数据库中查询出来所被跟踪的实体的值。如下： using (var ctx = new EfDbContext()) { var customer = GetCustomer(); var dataBaseCustomer = ctx.Customers .FirstOrDefault(d => d.Id == customer.Id); if (dataBaseCustomer != null) { ctx.Entry(dataBaseCustomer).CurrentValues.SetValues(customer); if (ctx.SaveChanges() > 0) { Console.WriteLine("更新成功"); } else { Console.WriteLine("更新失败"); } }
}; 关于EF更新方式讲了四种，其中有关细枝末节就没有再细说可自行私下测试，不知道用过EF的您们是否四种都知道以及每一种对应的场景是怎样的呢？对于数据更新我一般直接通过查询进行赋值的形式，当然我们也可以用AutoMapper，然后通过HasChanges方法来进行判断。 EntityFramework 6.x批量添加对于批量添加已经是EF 6.x中老掉牙的话题，但是依然有很多面试者不知道，我这里再重新讲解一次，对于那些私下不学习，不与时俱进的童鞋好歹也看看前辈们（不包括我）总经的经验吧，不知道为何这样做，至少回答答案是对的吧。看到下面的批量添加数据代码是不是有点想打人。 using (var ctx = new EfDbContext()) { for (var i = 0; i <= 100000; i++) { var customer = new Customer { Email = "2752154844@qq.com", Name = i.ToString() }; ctx.Customers.Add(customer); ctx.SaveChanges(); } }; 至于原因无需我过多解释，如果您这样操作，那您这一天的工作大概也就是等着数据添加完毕，等啊等。再不济您也将SaveChanges放在最外层一次性提交啊，这里我就不再测试，浪费时间在这上面没必要，只要您稍微懂点EF原理至少会如下这么使用。
var customers = new List<Customer>(); using (var ctx = new EfDbContext()) { for (var i = 0; i <= 100000; i++) { var customer = new Customer { Email = "2752154844@qq.com", Name = i.ToString() }; customers.Add(customer); } ctx.Customers.AddRange(customers); ctx.SaveChanges(); }; 如果您给我的答案如上，我还是认可的，要是第一种真的说不过去了啊。经过如上操作依然有问题，我们将所有记录添加到同一上下文实例，这意味着EF会跟踪这十万条记录， 对于刚开始添加的几个记录，会运行得很快，但是当越到后面到达到十万时，EF正在追踪更大的对象图，您们觉得恐怖不，这就是您不懂EF原理的代价，还对其进行诟病，吐槽性能可以，至少保证你写的代码没问题吧，我们进一步优化需要关闭自调用的DetectChanges方法无需进行对每一个添加的实体进行扫描。
var customers = new List<Customer>(); using (var ctx = new EfDbContext()) { bool acd = ctx.Configuration.AutoDetectChangesEnabled; try { for (var i = 0; i <= 100000; i++) { var customer = new Customer { Email = "2752154844@qq.com", Name = i.ToString() }; customers.Add(customer); } ctx.Customers.AddRange(customers); ctx.SaveChanges(); } finally { ctx.Configuration.AutoDetectChangesEnabled = acd; } }; 此时我们通过局部关闭自调用DetectChanges方法，此时EF不会跟踪实体，这样将不会造成全盘扫描而使得我们不会处于漫长的等待，如此优化将节省大量时间。如果在我们了解原理的前提下知道添加数据到EF上下文中，随着数据添加到集合中也会对已添加的数据进行全盘扫描，那我们何不创建不同的上下文进行批量添加呢？未经测试在这种情况下是否比关闭自调用DetectChanges方法效率更高，仅供参考，代码如下：
public static class EFContextExtensions { public static EfDbContext BatchInsert<T>(this EfDbContext context, T entity, int count, int batchSize) where T : class { context.Set<T>().Add(entity);
if (count % batchSize == 0) { context.SaveChanges(); context.Dispose(); context = new EfDbContext(); } return context; } } static void Main(string[] args) { var customers = new List<Customer>(); EfDbContext ctx; using (ctx = new EfDbContext()) { for (var i = 0; i <= 100000; i++) { var customer = new Customer { Email = "2752154844@qq.com", Name = i.ToString() }; ctx = ctx.BatchInsert(customer, i, 100); } ctx.SaveChanges(); }; Console.ReadKey(); } 总结不喜勿喷，敢问您们到底会不会用EntityFramework啊，EF 6.x性能令人诟病但是至少得保证您们写的代码没问题吧，您们可结合Dapper使用啊，担心EF 6.x性能不行，那请用EntityFramework Core吧，你值得拥有。谨以此篇批判那些不会用EF的同行，还将EF和并发扯到一块，EF不是用来抵抗并发，它的出现是为了让我将重心放在梳理业务对象，关注业务上，有关我对EF 6.x和EF Core 2.0理解全部集成到我写的书《你必须掌握的EntityFramework 6.x与Core 2.0》最近即将出版，想了解的同行可关注下，谢谢。 |