本篇原文链接:Advanced Entity Framework Scenarios 本篇主要讲一些使用Code First建立ASP.NET WEB应用的时候除了基础的方式以外的一些扩展方式方法: 1.Performing Raw SQL Queries (执行真正的SQL语句) 2.Performing no-tracking queries (执行无跟踪的SQL语句) 3.Examining SQL sent to the database (检查发到数据库的SQL语句) Performi

一. 简介 上一个章节中,也介绍了立即加载和延迟加载,但上一个章节是针对单表而言的,不含外键,立即也好,延迟也好,都是指单表中的数据.但本章节重点介绍的三种加载方式均是针对含(导航属性.外键)的情况下,查询主表,从表中的数据加载情况. 下面准备两张表:Student和StudentAddress两张表,一对一 or 零 的关系,实体结构如下,通过CodeFirst来反向生成数据库. /// <summary> /// 学生表(一个学生只能有一个地址或没有地址) /// </summary

ASP.NET MVC深入浅出(被替换)   一. 谈情怀-ASP.NET体系 从事.Net开发以来,最先接触的Web开发框架是Asp.Net WebForm,该框架高度封装,为了隐藏Http的无状态模式,ViewState功不可没,通过的控件的拖拽和绑定,很快就可以搭建出来一个Web项目,其开发速度远胜Java.PHP,当年Web项目并不很重视体验,没有今天响应式,没有各种前端js框架,所以在当年的WebForm,微软是以引以为豪的. 该框架毕竟有时代局限性,随着前端的崛起,随着人们对项目体验

你所不知道的库存超限做法 在互联网企业中,限购的做法,多种多样,有的别出心裁,有的因循守旧,但是种种做法皆想达到的目的,无外乎几种,商品卖的完,系统抗的住,库存不超限.虽然短短数语,却有着说不完,道不尽,轻者如释重负,重者涕泪横流的架构体验. 但是,在实际开发过程中,库存超限,作为其中最核心的一员,到底该怎么做,如何做才会是最合适的呢? 今天这篇文章,我将会展示给大家库存限购的五种常见的做法,并对其利弊一一探讨,由于这五种做法,有的在设计之初当做提案被否定掉的,有的在线上跑着,但是在没有任何单元

需求 基于MTK 8.1平台定制导航栏部分,在左边增加音量减,右边增加音量加 思路 需求开始做之前,一定要研读SystemUI Navigation模块的代码流程!!!不要直接去网上copy别人改的需求代码,盲改的话很容易出现问题,然而无从解决.网上有老平台(8.0-)的讲解System UI的导航栏模块的博客,自行搜索.8.0对System UI还是做了不少细节上的改动,代码改动体现上也比较多,但是总体基本流程并没变. 源码阅读可以沿着一条线索去跟代码,不要过分在乎代码细节!例如我客制化这个需

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 第五章 加载实体和导航属性 实体框架提供了非常棒的建模环境,它允许开发人员可视化地使用映射到数据库中的表.视图.存储过程以及关系中的实体类型.本节将向你展示如何控制查询操作中的关联实体的加载. 实体框架的默认行为是只加载应用程序直接需要的实体.通常情况下,这正是你需要的.如果实体框架通过一个或多个关联积极地加载关联实体,最终,你很有可能得到超过你需求的实体.这不但增加了内存占用,而且还影响了

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-2  预先加载关联实体 问题 你想在一次数据交互中加载一个实体和与它相关联实体. 解决方案 假设你有如图5-2所示的模型. 图5-2 包含Customer和与它相关联信息的实体 和5-1节一样,在模型中,有一个Customer实体,一个与它关联的CustomerType和多个与它关联的CustomerEamil.它与CustomerType的关系是一对多关系,这是一个实体引用(译注:Cu

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-5  加载完整的对象图 问题 你有一个包含许多关联实体的模型,你想在一次查询中,加载完整的对象图实例.一般地,当一个页面视图需要呈现关联实体集时,你会选择这种方法,而不是延迟加载,因为延迟加载是通过一系列的短小查询来获取关联实体的. 解决方案 假设你有如图5-20所示的概念模型.每门课程有很多节,每一节由一个老师教多名学生. 图5-20 一个包含许多关联实体的模型 使用Include()

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-7  在别的LINQ查询操作中使用Include()方法 问题 你有一个LINQ查询,使用了类似这样的操作 group by,join,和where:你想使用Include()方法预先加载额外的实体.另外你想使用Code-First来管理数据访问. 解决方案 假设你有如图5-22所示的概念模型 图5-22 一个简单的包含Club和Event以及它们之间一对多关联的模型 在Visual S

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-9  关联实体过滤和排序 问题 你有一实体的实例,你想加载应用了过滤和排序的相关实体. 解决方案 假设你有如图5-24所示的概念模型 图5-24 一个酒店预定系统的模型 假设我们有一个酒店(Hotel)实体,使用代码清单5-22,获取酒店的商务套房(executive suite),查看是否被预定,并按房价排序. 代码清单5-22.通过方法Entry()和Query()显式加载实体集合,

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-11  测试实体引用或实体集合是否加载 问题 你想测试关联实体或实体集合是否已经加载到上下文中,另外你想使用Code-First来管理数据访问. 解决方案 假设你有如图5-26所示的概念模型 图5-26 一个包含projects,managers和contractors的模型 在Visual Studio中添加一个名为Recipe11的控制台应用,并确保引用了实体框架6的库,NuGet可

翻译的初衷以及为什么选择<Entity Framework 6 Recipes>来学习,请看本系列开篇 5-13  过滤预先加载的实体集合 问题 你想过滤预先加载的实体集合,另外,你想使用Code-First来管理数据访问 解决方案 实体框架不支持直接使用Include()时过滤关联实体集合,但我们可以通过创建一个匿名类型来完成同样的事情,匿名类型包含实体和要过滤的关联实体集合. 假设你有如图5-28所示的概念模型 图5-28 一个包含movies(电影)和它的categories(目录)的模

关系与导航属性 本主题概述实体框架如何管理实体间的关系.还对如何映射和操作关系提供了一些指南. 关系.导航属性和外键 在关系数据库中,表之间的关系(也称为关联)是通过外键定义的.外键 (FK) 是用于在两个表的数据之间建立并强制链接的一列或列组合.有三种关系类型:一对一.一对多和多对多.在一对多关系中,外键是在表示关系多端的表上定义的. 多对多关系涉及定义第三个表(也称为接合或联接表),主键由来自两个相关表的外键组成.在一对一关系中,主键还用作外键,两个表都没有单独的外键列. 下图显示的两个表存

回到目录 今天在进行EF开发时,遇到一个问题,在进行join查询时,类中的一个集合类型的导航属性,在给它赋值时,将查询出来的结果ToList()后,出错了,linq to entity不支持这种操作,而在linq to sql里这是合法的,在EF中是不行的,所以,使用了替换方法,就是类型强转,代码如下: var linq = from student in base.GetModel() join user_classrooms in new TsingDa_NewLearningBarRepo

回到目录 对EF开发来说,导航属性肯定都用过,事实上,它是由VS IDE工具根据你的数据库关系结构自动生成的外键属性,在类视图中可以看到相关属性,它是以外键表名来标识的,如果是一对多的关系,那么,它会为属性加上ICollection泛型集合用来标识,而今天我们要说的当然不是自动生成的,而是手动加的属性,这样属性需要我们手动进行join,然后把它按需赋值,而使用include当然是无效的,呵呵. 一般地,我们习惯上把集合属性定义为List<T>,但是,对于linq to entities来说,这

一.首先了解下Entity Framework 自动关联查询: Entity Framework 自动关联查询,有三种方法:Lazy Loading(延迟加载),Eager Loading(预先加载),Explicit Loading(显式加载),其中Lazy Loading和Explicit Loading都是延迟加载. (注:由于Entity Framework版本的不同,以及采用不同的模式(DB First,Model First,Code First)来构建的Entity,最终导致可能自

对于两张表A.B多对多的关系中,A的导航属性中有B,B的导航属性中有A,这样Json.net对A或者B对象序列化时会形成死循环 所以对于导航属性要加标签 首先在A.B实体类工程(Model)中引用Json.ne 然后对导航属性加不序列化标签([JsonIgnore]) //------------------------------------------------------------------------------ // <auto-generated> // 此代码是根据模板生成

总之,要让所有的东西,都被DbContext管理状态 1.查出来,改了,再提交 2.new 出来,attach,再改,再提交 以上两种都较好理解 3.new出来,改了,再attach,在改状态,再提交 改状态这里,不是和普通属性一样Property(x=>x.?).IsModify=true,导航属性不能用这样的方式 因为导航属性对应的是一个集合,而状态是要对应到集合里的每个元素具体的状态,而不是集合整个的状态 ((IObjectContextAdapter)db).ObjectContext.

文章索引和简介 通过上一篇的学习 我们把demo的各种关系终于搭建里起来 以及处理好了如何映射到数据库等问题 但是 只是搭建好了关系 问题还远没有解决 这篇就来写如何查找导航属性 和查找导航属性的几种方式 已经跟踪生成的SQL来检测是否满意 通过这节学习 来明白什么时候用哪个~~ 一.三种加载 1.延迟加载 这是原文中的图 大家可以去看下  我模仿上面的做了个测试  出现了  已有打开的与此 Command 相关联的 DataReader,必须首先将它关闭. 我的解决办法是    var dep

首先谈谈自己对EF的接触的过程吧,最先接触EF只是因为EF支持从数据库把关系扒下来,可以省掉自己写Select.Update.Insert这些SQL语句,而且修改非常方便,后来在使用的过程中发现导航属性这个关系,然后才慢慢知道数据库的索引是什么,由于自己接管的是大学生社团的数据库,大多时候创建者并不会考虑表的联系,一般创个主键就完事了(顺便吐槽一句,握草,数据库的表名和列名是什么鬼全用拼音首字母,为了兼容前面的内容我们还得花一半时间猜你们的列名,简直醉了,除了ID这个英文他们会,你们的英语是体育

一对多关系 项目中最常用到的就是一对多关系了.Code First对一对多关系也有着很好的支持.很多情况下我们都不需要特意的去配置,Code First就能通过一些引用属性.导航属性等检测到模型之间的关系,自动为我们生成外键.观察下面的类: public class Destination { public int DestinationId { get; set; } public string Name { get; set; } public string Country { get; s