Ado.Net，用了N多年，Entity Framework也关注了很多年。 每当项目转型的时候，就花费大巴的时间，学习一番，潮流的东西。 这个Orm很多，这个EF很火，这么多年了，我还是不敢用，虽然比当年好多了。
当年也就是12年的时候，实体类是乱七八糟的一大堆，属性里是带功能的，不是单纯的实体类。而且，其他数据库支持的不是特别好。现在，实体类清丽了 很多，想着，用一下吧，却又把我吓到了，其实也没有特别的不好，只是太乱了。 EF 官方的增删该查，最好的就是查询，剩下的三个，不敢恭维，基本的功能还行，如果涉及到批量的操作，就没辙了（自己写扩展除外）
据说，Entity Framework.Extend 扩展的不错，社群里，一大票人都知道，也都看过，怎么到我这，就是越看越不敢用，越看越不放心了。
批量操作，可以说是一大特色，却这个批量操作，写起来倒是很顺溜，仔细一研究，他是直接就生成sql语句执行了，而且还是自己生成了个Command执行的，EF的拦截器根本拦截不到
缓存，倒是挺不错的，这也是个重要的功能，也就是用了EF.Extend的缓存
AuditLog，这个日志审计功能，完全就不该存在，这样说是因为，通过批量操作的，都无法 审计记录。
为什么，我不敢用EF呢？
前些年是DataBase First，后来是Mode First，现在是Code First，既然这样迭代，肯定是EF在改进。但是，我觉得，越改越凌乱了。Code First，让代码更加的繁琐了，关键是，C#代码声明的实体映射与数据库不一样，是会报错的，例如，字段的长度 不一样。而，我只是想 用一下 linq 的溜溜的写法，不再去拼接sql语句。用了EF之后，太多的束缚，如果EF能精简就好多了，而我又精力有限，写不了 Orm 了。 只能自己写Sql了。
其实，我需要的只是，一个精简的EF
个人觉得，我自己写的代码，除了不能Linq，其他的都还好，有 延迟加载，有缓存，有实体生成工具。
这样挺好，待下次了再学习EF 吧。如果哪个项目，必须要用EF，那我就跟着大拿用吧，让我自己用，肯定是不会用的。
有这么个业务逻辑，怎么实现
1 如果用EF，写这么个逻辑是没办法正常执行的 2 1、先保存一个对象 3 2、删除ID>5的数据 4 3、保存一个对象 5 4、修改ID>5的对象，（条件里包含第一次保存的对象） 6 然后，EF，貌似实现不了这样的事务
正常的代码应该是类似这样的
1 using (TransactionScope transaction = new TransactionScope()) 2 { 3 t.Area.Add(new Area() { Code = "A", Name = "A" }); 4 var dfe4 = from a in t.Area where a.Id > 5 select a; 5 dfe4.Delete(); 6 t.Area.Add(new Area() { Code = "B", Name = "B" }); 7 (from a in t.Area where a.Id > 5 select a).Update(a2 => new Area() { Name = "IM:" }); 8 9 var f234 = from a in t.Area where a.Id > 5 && a.Name == "IM:" select a; 10 Area a234 = f234.First(); 11 if (a234 != null) 12 { 13 a234.Name = "IM:234"; 14 Area a235 = f234.Where(e => e.Id == a234.Id + 2).FirstOrDefault(); 15 if (a235 != null) 16 { 17 t.Area.Remove(a235); 18 } 19 } 20 t.SaveChanges(); 21 Console.WriteLine("------------"); 22 Console.ReadLine(); 23 transaction.Complete(); 24 }
这是使用了 EntityFramework.Extend的写法。 这样执行会有问题么？
请看这两张图
执行顺序不对你说，如果是在一个系统内，恰好有先后顺序的依赖关系，那就真的出问题了。