EF 初探
EF6学习笔记十：原始查询，在EF中使用SQL语句
EF6学习笔记⼗：原始查询，在EF中使⽤SQL语句EF⾥⾯当然也可以直接使⽤SQL语句了，⽐如有些复杂的查询⽤LINQ写不了的，还有存储过程那些东西。
EF为查询操作提供了两个⽅法：ctx.Database.SqlQuery<T>()、ctx.DbSet<T>.SqlQuery() （ctx表⽰上下⽂对象）为Insert、Update、Delete 操作提供了两个⽅法：ExecuteSqlCommand()、ExecuteSqlCommandAsync()我们来弄⼀弄这些⽅法，看看怎么回事原始查询ctx.Database.SqlQuery<T>() 和 ctx.Dbset<T>.SqlQuery() 两个⽅法的区别，最先要说的就是，ctx.Database.SqlQuery<T>()查询出的数据没有被上下⽂追踪，另⼀个⽅法查询出的实体则被追踪了来看ctx.Database.SqlQuery<T>() 查询出实体的状态为Detachedusing(EFDbContext ctx = new EFDbContext){var res = ctx.Database.SqlQuery<Product>("select *from tb_products");//var state = ctx.Entry(res).State; // 报错实体 DbRawSqlQuery不是上下⽂模型的⼀部分var first = res.FirstOrDefault();var state = ctx.Entry(first).State;Console.WriteLine(state); // Deteched}View Code来看ctx.Dbset<T>.SqlQuery() 实体状态为Unchangedvar res = ctx.Products.SqlQuery("select * from tb_products");var pro = res.FirstOrDefault();var state = ctx.Entry(pro).State;Console.WriteLine(state); // UnchangedView Code这是他们之间的第⼀个区别，不过这个倒没什么⼤碍，对吧。
entityframework 原理
entityframework 原理Entity Framework (EF) 原理简介Entity Framework (EF) 是由微软开发的一种对象关系映射（ORM）框架，用于在应用程序和数据库之间进行数据访问。
它提供了一种方便的方式来处理数据库操作，简化了开发过程并提高了开发效率。
EF 的原理基于三个核心概念：实体（Entity）、上下文（Context）和映射（Mapping）。
下面我们将详细介绍每个概念以及它们之间的关系。
1. 实体（Entity）：在 EF 中，实体是指映射到数据库表的对象。
每个实体类代表数据库中的一条记录。
通过定义实体类的属性来映射数据库表的列，实体类的实例可以直接操作数据库的数据。
2. 上下文（Context）：上下文是用来管理实体对象的一个重要概念。
它充当了连接应用程序和数据库之间的桥梁。
上下文负责对实体的CRUD操作（增删改查），并且跟踪实体的状态变化。
3. 映射（Mapping）：映射是实现实体和数据库表之间关系的过程。
在 EF 中，开发者可以使用多种方式进行映射，包括通过特性、配置文件或者使用 Fluent API 来定义实体和数据库表之间的映射关系。
EF 的工作流程如下：1. 创建实体类和上下文类：首先，我们需要定义实体类来映射数据库表，并创建一个继承自 DbContext 的上下文类。
2. 配置映射关系：通过特性、配置文件或 Fluent API 来配置实体和数据库表之间的映射关系。
3. 使用上下文管理实体：在应用程序中，我们可以使用上下文类的实例来管理实体对象。
通过上下文的 SaveChanges 方法，可以将实体的变化保存到数据库中。
4. 生成 SQL 查询：EF 在底层会根据上下文的操作和映射关系生成相应的 SQL 查询语句，然后将其发送给数据库执行。
EF 的优势：1. 提高开发效率：EF 提供了一种简化数据库操作的方式，开发者无需编写大量的手动 SQL 查询语句，可以通过操作实体对象来完成对数据库的操作。
ef场景面试题
ef场景面试题EF（Entity Framework）是一个流行的.NET ORM（对象关系映射）框架，用于简化数据库操作和对象模型的交互。
以下是一些EF场景面试题，用于评估应聘者对EF的掌握程度：1.请简述Entity Framework的核心组件。
2.在EF中，什么是DbContext？它的作用是什么？3.描述一下DbSet<T>的使用场景和功能。
4.如何使用EF进行数据库迁移？5.什么是LINQ to Entities？它与LINQ to Objects有什么区别？6.如何在EF中使用延迟加载？7.什么是实体键和导航属性？它们在EF中有什么作用？8.如何在EF中实现一对多、多对一和一对一的关系？9.如何使用EF进行复杂查询和聚合操作？10.在EF中，如何处理并发问题？11.EF的性能优化有哪些常用技巧？12.当数据库连接失败时，如何处理EF中的异常？13.描述一下Entity Framework中的上下文生命周期管理。
14.如何使用EF进行数据分页和排序？15.请解释一下EF中的ChangeTracker和ObjectStateManager。
16.在EF中，如何处理数据库事务？17.如何使用EF进行数据插入、更新和删除操作？18.描述一下EF中的Code First、Database First和Model First的开发方式。
19.请解释一下EF中的Fluent API和Data Annotations。
20.在EF中，如何处理离线数据和脏读问题？这些问题可以帮助你了解应聘者对Entity Framework的熟悉程度，包括基本概念、开发方式、性能优化等方面。
EF数据操作详解
EF数据操作详解1.数据Load延迟加载：当实体第⼀次读取时，相关数据没有加载；当第⼀次试图访问导航属性时，所需的导航数据⾃动加载，EF默认使⽤这种⽅式加载数据，尽量使⽤预先加载和显⽰加载。
优点:加载数据快缺点：数据库交互多次预先加载：当读取实体时，相关数据同时读取。
这通常会导致⼀个连接查询，查询所有所需的数据，使⽤Include⽅法指定预先加载。
优点: 数据库交互少缺点：加载实体多，数据量⼤时，变慢，会有很多冗余字段显⽰加载：这种加载⽅式类似于延迟加载，不同的是我们要在代码中明确地查询相关数据，导航属性是⼿动控制的，需要调⽤Collection.Load⽅法获取集合，调⽤Reference.Load⽅法获取单个实体来加载相关数据。
优点: 加载数据快，导航属性如何加载可以⾃⼰控制，通常关联实体集合的数量被限制时，使⽤Load⽅法缺点：需要⾃⼰控制，数据库交互多次，交互次数由⾃⼰控制CompiledQuery：提供对查询的编译和缓存以供重新使⽤。
当相同的查询需要执⾏很多遍的时候，那么我们可以使⽤ComplieQuery将查询的语句进⾏编译以便下次使⽤，这样可以免去对同⼀语句的多次处理，从⽽改善性能优点：减少查询表达式树编译次数AsNoTracking：如果数据是只读操作，⽤AsNoTracking取消追踪，提升性能。
SqlQuery：对于复杂的查询或存储过程的使⽤，考虑⽤SqlQuery操作原⽣sql。
Skip：分页在数据库中分页，不要再内存中分页，以提升性能IQueryable和IEnumerable：IQueryable返回的是查询表达式，也就是说⽣成了SQL查询语句但是却还没有与数据库进⾏交互。
IEnumerable则是已经执⾏查询数据库的操作且数据保存在了内存中，所以在进⾏条件拼接的时候⼀定要在IQueryable类型后⾯追加Where条件语句，⽽不是等到ToList之后再开始写条件，以提升性能。
简要介绍EF(实体框架).docx
一、实体框架（Entity Framework）介绍实体框架（Entity Framework）是微软以为基础开发出来的对象关系映射（ORM）解决方案，它解决了对象持久化问题，将程序员从编写麻烦的SQL语句当中解放出来。
相对于传统的ADO等各种数据库操纵技术来说，微软的更为先进，它封装了很多底层操作，抽象了接口，针对接口编程，将调用统一化。
但这种方法也已经满足不了项目开发的应用了，于是我们进入了对象关系映射（ORM）的时代！先看个例子，我们新建数据库DemoDB和数据表UserInfo：EF是.Net平台下的一个组件，在项目下右击添加项，添加一个实体数据模型，选择从数据库生成，选择这个数据库和表，就能得到如下项：双击这个edmx进去，可以看到：这个亲切的模型和数据库表是完全对应的，当实体或者数据库变化时，我们可以让他们同步修改。
生成的cs文件里保存了实体的信息，打开它，这个类分为上下文和实体两部分。
实体的基元属性当中保存了表字段对应的信息，如：上下文则是程序员操作数据库的入口，里面有编程时用的东西。
二、一个小例子既然上下文是操作数据库的入口，所以我们要先new一个上下文，然后创建实体，以面向对象的方式写属性，然后入库，保存修改。
（NHibernate里这上下文叫“session”。
）这就写完了。
我们再也不用写蛋疼的代码了！这段代码相当于调用了一个“中间层”，再由它调用数据库操纵方法。
三、这背后到底发生了什么？首先写数据库要有链接字符串，显然在App.Config里，打开看一看：这连接字符串后面的部分就是一般的链接字符串，EF其实是跨数据库的，注意第六行，可以通过这里换数据库。
在这前面，它指定了csdl、ssdl和msl文件，这些文件在我们项目里找不到，它们到底在哪呢？在添加进来的实体对象上右击-打开方式-以XML方式打开它，我们立刻看到SSDL部分：SSDL是存储摸型的定义，在这里我们能很清楚地看到XML里保存了类名和数据库表中的信息。
ef作用域
ef作用域一个程序中的每个函数及其参数和变量都拥有自己的作用域，作用域定义了这些函数和变量在程序中的可见性和访问性。
作用域规定了一个程序中的某个位置上那些标识符可见和可访问，同时也决定了如何解析名称冲突。
在本文中，我们将探讨EF （Entity Framework）中的作用域以及其相关参考内容。
1. EF作用域概述：在EF中，作用域是指在上下文中创建和使用实体对象的范围。
作用域控制了实体对象的生命周期和持久化，并确保只有在适当的时候才能访问它们。
作用域中的实体对象可以保存在数据库中，也可以被丢弃而不进行持久化。
2. EF作用域的管理：EF作用域由DbContext类来管理。
每个DbContext实例都代表一个作用域，它可以访问特定的数据库，并负责创建、更新和删除实体对象。
在一个作用域内，可以使用DbContext的各种API来操作实体对象和执行数据库操作。
3. EF作用域的创建：EF作用域可以通过创建DbContext实例来创建。
可以根据需要创建多个DbContext实例，每个实例代表一个独立的作用域。
创建DbContext实例的方式有多种，包括使用构造函数创建、继承DbContext类并创建自定义的DbContext子类等。
4. EF作用域的范围：EF作用域的范围可以是整个应用程序、单个请求、某个事务等。
根据具体的需求，可以决定每个作用域的范围和生命周期。
作用域的范围和生命周期会影响到实体对象的生命周期，以及对数据库的访问和效率。
5. EF作用域的嵌套：EF允许在作用域内嵌套其他作用域。
通过嵌套作用域，可以实现对实体对象和数据库操作的更细粒度的控制。
嵌套作用域的创建方式类似于创建普通的作用域，只是需要使用不同的DbContext实例。
总结：EF作用域在应用程序中起到非常重要的作用，它决定了实体对象的可见性和访问性，并控制了数据库操作的范围和效率。
了解EF作用域的概念和管理方式，对于编写高效且可维护的EF代码非常重要。
EF教程
目录EF框架step by step(1)—Database-First (2)EF框架step by step(2)—Model-First (9)EF框架step by step(3)—Code-First (12)EF框架step by step(4)—DBcontext应用于已存在数据库 (17)EF框架step by step(5)—处理实体简单属性 (19)EF框架step by step(6)—处理实体complex属性 (23)EF框架step by step(7)—Code First DataAnnotations(1) (25)EF框架step by step(8)—Code First DataAnnotations(2) (29)EF框架step by step(9)—Code First Fluent API (31)EF框架step by step(1)—Database-First Entity Framework 是微软以 为基础所发展出来的对象关系对应(O/R Mapping) 解决方案，现已经包含在Visual Studio 2008 Service Pack 1 以及.NET Framework 3.5 Service Pack 1 中发布。
目前最新版本为4.1，可以点此下载。
Entity Framework 以Entity Data Model (EDM) 为主，将数据逻辑层切分为三块，分别为Conceptual Schema, Mapping Schema 与Storage Schema 三层，其上还有Entity Client，Object Context 以及LINQ 可以使用。
在最新4.1版本中，增加了DbContext API及Codefirst，DbContext API 是基于ObjectContext和其他一些类型抽象出的一个简单的API，并进行了优化。
EF系统学习-DCBI-博客园
EF系统学习-DCBI-博客园EF 系统学习2011-03-24 01:52 by DCBI, 90 visits, 收藏, 编辑EF中几个重要的，如ObjectContext、ObjectQuery、、EntityClient、Linq to Entity以及ESQL相关处理。
而linq只是一个技术的应用。
EF并发冲突【Fixed】，并发处理；继承，多表关联；事务，存储过程处理；复杂类型处理。
具体项目应用过程中队EF的应用；效率，解耦；还有就是EF优化---缓存。
GetObjectByKey、延迟加载、CompiledQuery。
linq to entity【objectcontext】与linq to sql【datacontext】及entityclientmon.DbTransaction与System.Transactions.TransactionScopeTransactionScope可解决[死锁(两个Context使用DbTransaction)]可解决死锁TransactionScope代码段;using(System.Transactions.TransactionScope tc = new TransactionScope()) { try{ myContext context1 = new myContext(); DBItem item1 = new DBItem(); item1.ItemID = "w"; item1.ItemMatter = "wxwinter"; context1.AddObject("DBItem", item1); context1.SaveChanges(); myContext context2 = new myContext(); DBItem item2 = new DBItem(); item2.ItemID = "w"; item2.ItemMatter = "wxd"; context2.AddObject("DBItem", item2); context2.SaveChanges(); plete(); } catch{ } }DbTransaction代码段：myContext context1 = new myContext(); DBItem item1 = new DBItem(); item1.ItemID = "w"; item1.ItemMatter = "wxwinter"; context1.AddObject("DBItem", item1); if (context1.Connection.State != ConnectionState.Open) { context1.Connection.Open(); } mon.DbTransaction tran = context1.Connection.BeginTransaction();context1.SaveChanges(); try{ myContext context2 = new myContext(); DBItem item2 = new DBItem(); item2.ItemID = "w"; item2.ItemMatter = "wxd"; context2.AddObject("DBItem", item2); context2.SaveChanges(); mit(); } catch{ tran.Rollback(); }分类: NET。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
近期公司打算使用EF，于是这两天我特地研究了它的一些特性。
本文记录的是我的一些研究成果。
哎哟，说成果是不是大了点？ps：对于EF，每次它有新版发布，我都一笑而过，为啥？因为我一直非常安逸于使用一个叫IQToolkit的开源组件，该组件作者有专门写了一系列博文记录IQToolkit从无到有的诞生历程，我估计市面上很多基于Linq的ORM或多或少都借鉴过他的经验[和代码]。
我从中也受益良多，虽然偶有不足，但大部分略作改造即可弥补。
它和EF相比，恰如穷屌丝和高富帅，下面有几个地方我会拿它们作一对比。
1、原有项目引入EFEF有个DB First模式，可以根据数据库自动生成POCO实体和映射关系，生成的实体是与数据表一一对应，各自独立的。
若原有项目已存在实体类库，由于一些原因想保留之，比如各实体可能共享一些基类或接口，以便在业务层针对基类抽取共同逻辑，这些继承关系不想抛弃。
我们可以这么做，当新建edmx文件后，删除所有自动生成的POCO，包括xxx.tt模板文件一同删除，否则当修改edmx时，系统会根据模板重新生成POCO。
删完之后将xxx.Context.cs文件中的实体引用改为原项目实体。
我们还可以修改xxx.Context.tt模板文件，使之生成的相应DbContext类（在xxx.Context.cs中）符合我们的要求。
2、EF是主键控EF的上下文特性需要能唯一标识实体的方法，这无可厚非，然而EF非常固执地只认主键，当数据表没有主键时，对应的实体就不能Update和Delete，这是一个非常严重的“Bug”。
很多人会问：“难道表不应该有主键吗？”不幸的是，这种情况很普遍。
主键存在的意义是标示数据表中的某一条记录，以便于我们能通过它去精确定位[、更新和删除]数据。
但很多时候我们并不会独独去get某一条记录。
比如发货单，分为主表和子表，对子表的都是整单查询操作，或者数据汇总，或者根据业务字段作为索引去查，因此并不会为子表的记录新增一个毫无意义的主键。
另一种考虑是，由于主键对Insert操作的效率影响，常用非聚集索引代替，以尽量减少全表排序。
当我们试图Delete没有主键的表数据时:所幸，微软似乎意识到这个问题，于是默默地写了一篇How to: Create an Entity Key When No Key Is Inferred。
不过这篇文章里的内容虽然号称是最新版本，但是跟我实际所得有很大出入，文中说没有主键的数据表是不会产生Model的（原话：If no entity key is inferred, the entity will not be added to the model.），I say：非也。
然后后续的步骤更加不知所云。
下面说说我是怎么处理的：1.简单起见，设有一张库存表，表结构：，木有主键，now，从数据库生成Model；2.用记事本打开edmx文件，我们会找到两处同样的片段：1 <EntityType Name="Stock">2 <Key>3 <PropertyRefName="StorageID" /> 4 <PropertyRef Name="ProductID" /> 5<PropertyRef Name="Quantity" /> 6 </Key> 7 <PropertyName="StorageID" Type="int" Nullable="false" /> 8 <PropertyName="ProductID" Type="int" Nullable="false" /> 9 <PropertyName="Quantity" Type="int" Nullable="false" />10 </EntityType>一个是在SSDL节点下，一个是CSDL节点（就刚才的文说在SSDL中是注释掉的，其实没有；说CSDL中没有，其实有的），由于没有主键，框架自作聪明地将所有字段都列为复合主键，而且该片段对应的实体是只读的……由于StorageID和ProductID已经组成了一个非聚集唯一索引（这么做的原因前已表述），对于UD操作来说等同于主键，因此删除<PropertyRef Name="Quantity" />片段变为：1 <EntityType Name="Stock">2 <Key>3 <PropertyRefName="StorageID" />4 <PropertyRef Name="ProductID" />5 </Key>6 <Property Name="StorageID" Type="int" Nullable="false" />7 <Property Name="ProductID" Type="int" Nullable="false" />8 <PropertyName="Quantity" Type="int" Nullable="false" />9 </EntityType>这一步骤也可以直接在关系图中设置3.继续在记事本中查找<EntitySet Name="Stock"EntityType="DistributionModel.Store.Stock" store:Type="Tables"store:Schema="dbo" store:Name="Stock" />这一段，改为<EntitySet Name="Stock"EntityType="DistributionModel.Store.Stock" store:Type="Tables" Schema="dbo" />，目测store：XXX就是表明对应实体为只读。
4.在Stock实体属性StorageID和ProductID加上特性[Key]。
完毕。
3、什么！？EF的字典里没有“批量”的概念？上述方法“完美地”解决了主键问题，我们来试试看：1 [TestMethod]2 public void TestMethod6()3 {4 using (var entities= new DistributionEntities()) 5 { 6 var test =entities.Stock.Where(o => o.Quantity == 0).ToList(); 7 foreach (var t in test) 8 entities.Stock.Remove(t); 9 entities.SaveChanges();10 }11 }不出所料，执行成功，不过我要说的并不是这个，而是这种删除模式——先从数据库里取出要删的数据，然后代码层跟上下文说我要将这些数据从表里删除，上下文再去执行最后的步骤——是不是很坑爹？我相信您肯定有蛋疼的感觉（这里假定你是男人），and，（人生最害怕的就是这个and！）如果您去到数据库里走一遍跟踪，想看看entities.SaveChanges()做了什么事，您的蛋基本上就碎了。
没错，EF的上下文特性的前提是所有对数据的更改都要通过主键定位完成，这也就是第2条描述的内容。
so，它会针对每个已编辑或已删除实体单独生成一条语句。
如果一次操作有上万个实体需要更新，效率会否有影响？不管怎样，有人按捺不住，写了一个扩展组件EntityFramework.Extended，可以通过NuGet 获取，可参看Entity Framework Batch Update and Future Queries。
现在我们可以这样：1 [TestMethod]2 public void TestMethod4()3 {4 using (var entities = new DistributionEntities())5 {6 entities.Stock.Delete(o => o.Quantity == 0);7 }8 }避免了往返数据库两次的尴尬，同时只生成了一条语句：DELETE [dbo].[Stock]FROM [dbo].[Stock] AS j0 INNER JOIN (SELECT [Extent1].[StorageID] AS [StorageID], [Extent1].[ProductID] AS [ProductID], [Extent1].[Quantity] AS [Quantity]FROM (SELECT [Stock].[StorageID] AS [StorageID], [Stock].[ProductID] AS [ProductID], [Stock].[Quantity] AS [Quantity] FROM[dbo].[Stock] AS [Stock]) AS [Extent1]WHERE 0 = [Extent1].[Quantity]) AS j1 ON (j0.[StorageID] = j1.[StorageID] AND j0.[ProductID] = j1.[ProductID] AND j0.[Quantity] = j1.[Quantity])似乎跟预想的有点不太一样，印象中，偶觉得，可能，大概，或许，Maybe不应该是这么长一段吧……在代码的世界中，追求的是短小精悍！于是我招呼屌丝IQToolkit给观众展示一下：1 [TestMethod]2 public void TestMethod5()3 {4 QueryGlobal distrContext = new QueryGlobal("DistributionConstr");5 distrContext.LinqOP.Delete<Stock>(o => o.Quantity == 0);6 }这里的distrContext可以理解为上下文，关于这点后面说。