一.概述 EF实体关系定义了两个实体互相关联起来(主体实体和依赖实体的关系,对应数据库中主表和子表关系). 在关系型数据库中,这种表示是通过外键约束来体现.本篇主要讲一对多的关系.先了解下描述关系的术语. (1) 依赖实体: 这是包含外键属性的实体(子表).有时称为 child . (2) 主体实体: 这是包含主/备用键属性的实体(主表). 有时称为 parent. (3) 外键:依赖实体(子表)中的属性,用于存储主表的主键属性的值. (4) 主键: 唯一标识的主体实体(主表)的属性. 这可能是

基于共享主键的一对一: this.HasRequired(t => t.TRDConInfo) .WithOptional(t => t.TRDFoundationProjCheck); 一对多 this.HasRequired(t => t.ComponentBelong) .WithMany(t => t.TRDConInfos) .HasForeignKey(d => d.ComponentBelongID); 多对多 this.HasMany(t => t.Co

刚开始使用 Entity Framework 的时候,由于没有静下心来认真理清关系,走了一些"痛不欲生"的弯路.而我们目前开发的项目都在使用 Entity Framework,为了避免其他人再经历"痛不欲生"的弯路.于是下定决心边“理清关系”边“写博客”.而写博客可以逼着自己把问题完整地解决,避免半 途而废.当写出这些文章,自己不知不觉对问题有了更深的理解. 温故而知新,通过这篇总结将自己对EF实体关系的理解回锅热一热,也许会有新的收获:感情也一样,当感情冷下来的时

通过 Entiy Framework实践系列 文章,理了理 Entity Framework 的实体关系. 为什么要写文章来理清这些关系?“血”的教训啊,刚开始使用 Entity Framework 的时候,由于没有静下心来认真理清关系,走了一些"痛不欲生"的弯路.而我们目前开发的项目都在使用 Entity Framework,为了避免其他人再经历"痛不欲生"的弯路.于是下定决心边“理清关系”边“写博客”.而写博客可以逼着自己把问题完整地解决,避免半 途而废.当写出

最近遇到了一个 EF Core 的恐怖问题,在添加数据时竟然会自动删除数据库中已存在的数据,经过追查发现是一个多余的实体关系配置引起的. modelBuilder.Entity<Question>() .HasOne(q => q.Owner) .WithOne(); 罪魁祸首就是上面的 WithOne() . 今天写了个非常简单的控制台程序重现了这个问题. 实体类 Question 的定义 public class Question { public int Id { get; set

0. 前言 在<C# 数据操作系列 - 5. EF Core 入门>篇中,我们简单的通过两个类演示了一下EF增删改查等功能.细心的小伙伴可能看了生成的DDL SQL 语句,在里面发现了些端倪.没看的小伙伴也不急,这就贴出来. public class ModelA { public int Id { get; set; } public string Name { get; set; } public List<ModelB> ModelBs { get; } = new List

本文出自8天掌握EF的Code First开发系列,经过自己的实践整理出来. 本篇目录 理解Code First及其约定和配置 创建数据表结构 管理实体关系 三种继承模式 本章小结 本人的实验环境是VS 2012,windows 7,MSSQL Server 2008 R2. 上一篇<第一个Code First应用>简单介绍了如何使用EF的Code First方式创建一个项目,也介绍了如何进行简单的CRUD以及数据库模式的改变.这一篇,我们会深入学习领域建模需要注意的地方以及实体之间关系的管理

由于逻辑需要,我希望能在EF Core实例化实体时,拿到实体并执行相关代码,所以我就研究了一番EF Core,得到以下方法. 1.创建实体初始化类,继承EntityMaterializerSource public class ComBoostEntityMaterializerSource : EntityMaterializerSource { public ComBoostEntityMaterializerSource(IMemberMapper memberMapper) : base

返回<8天掌握EF的Code First开发>总目录 本篇目录 理解Code First及其约定和配置 创建数据表结构 管理实体关系 三种继承模式 本章小结 自我测试 本篇的源码下载:点击下载 先附上codeplex上EF的源码:entityframework.codeplex.com,此外,本人的实验环境是VS 2013 Update 5,windows 10,MSSQL Server 2008. 上一篇<第一个Code First应用>简单介绍了如何使用EF的Code Firs

在上一篇文章中我用递归方法实现了管理菜单,在上一节我也提到要考虑用缓存,也算是学习一下.Net Core的缓存机制. 关于.Net Core的缓存,官方有三种实现: 1.In Memory Caching 我理解是在内容中实现,这种方法适用于单服务器的生产环境. 2.a Distributed Cache 分部式缓存实现. 3.Response Cache 这种方式我理解为客户端缓存. 今天我只用了第一种实现方法,内存中缓存,之所以用这种方法我是觉得我这里用缓存的初衷是为了减少访问数据库的次数,

对于SQL Server.MySql.Oracle等这些传统的数据库,基本都是关系型数据库,都是体现实体与实体之间的联系,在以前开发时,可能先根据需求设计数据库,然后在写Model和业务逻辑,对于Model类基本都是和表的字段对应着,而表中存的每条记录又和类的实例对象对应着,有了这个对照关系,就是能不能只在一边设计,在数据库设计表或在VS中设计Model,然后直接生成另一边,这样就省了好多时间成本.于是有了ORM,Object Relation Mapping,对象关系映射.既然可以根据Mode

在EF实体框架之CodeFirst二中也提到数据库里面一般包括表.列.约束.主外键.级联操作.实体关系(E-R图).存储过程.视图.锁.事务.数据库结构更新等.前面几篇博客把表.存储过程.视图这些算是总结了一下,这篇的话主要总结下基本的约定类型. 1.主键 在数据库中主键是必不可少的,一般主键有业务主键和逻辑主键,而且主键有的还是联合主键在code first中也可以通过约定的形式映射到数据库——[Key]. [Key] public int ProductID { get; set; } 默认

学习笔记 1.json序列化ef实体是报错:“序列化类型为“System.Data.Entity.DynamicProxies.XXXX.... 对象时检测到循环引用.” 公司里用ef来生成实体.但是当我需要当ef构建完的实体里有其他实体的时候,比如说:在picture里有a实体.

实体类配置总结 Entity Framework 6 Code First 实践系列(1):实体类配置总结 2014-03-25 12:58 by TJerry, 719 阅读, 6 评论, 收藏, 编辑 EF实体类的配置可以使用数据注释或Fluent API两种方式配置,Fluent API配置的关键在于搞清实体类的依赖关系,按此方法配置,快速高效合理.为了方便理解,我们使用简化的实体A和B以及A.B的配置类AMap和BMap,来演示如何正确配置实体类关系的过程.  实体类配置 一.确定依赖关

在数据库中,表与表之间可能存在多种联系,比如,一对多,多对多的关系.当我们使用逻辑外键在数据库建立两张表之间的关系的时候,我们使用EF实体框架 必然也会将这种关系映射到我们的实体关系中来.所以,在我们做项目的时候,很多情况下我们都使用逻辑外键建立两张表之间的关系,从而避免删除等操作带来的种 种问题. 那么,我们的EF实体框架是怎么解决这种关联关系呢?假如给我们两张表,一张是用户表,另外一张是订单表.用户表与订单表是一对多的关系,我们来仿照EF 代码简单的写一个自己的框架(CodeOnly) 第一

在上一篇文章中,简单的介绍了使用Fluent API如何管理一对一的实体关系,在这篇文章中,接着介绍Fluent API如何管理一对多的实体关系. 要在数据库中配置一对多关系,我们可以依赖EF约定,还可以使用数据注解或Fluent API来显式创建关系.接下来使用捐赠者Donator和支付方法PayWay这两个类来举例子,这里的一对多关系是:一个人可以通过多种支付方式赞助我. 支付方式类PayWay结构如下: using System; using System.Collections.Gene

我们现在已经知道如何使用Code First来定义简单的领域类,并且如何使用DbContext类来执行数据库操作.现在我们来看下数据库理论中的多样性关系,我们会使用Code First来实现下面的几种关系: 1.一对一关系: one to one 2.一对多关系: one to many 3.多对多关系::many to many 首先要明确关系的概念.关系就是定义两个或多个对象之间是如何关联的.它是由关系两端的多样性值识别的,比如,一对多意味着在关系的一端,只有一个实体,我们有时称为父母:在关

导读:在之前,我们学过了三层框架,即:UI.BLL.DAL.我们将页面显示.逻辑处理和数据访问进行分层,避免了一层.两层的混乱.而后,我们又在经典三层的基础上,应用设计模式:外观.抽象工厂+反射,使得经典三层演变为了七层,在一定程度上降低了U层和B层,B层和D层的耦合. 可是,怎样解决D层和数据库之间的耦合?在三层操作中,D层都是直接访问数据库而对数据进行操作,在面向对象的应用中,这似乎显得不太合理,所以,我们应用了EF框架,解决了D层和数据库之间的耦合(这在之前已经说明过了).在三层中,我们应

一.知识回顾 到目前为止,自己学到的链接数据库操作已经经历了几个阶段,分别是:学生信息管理和(第一次)机房收费时的直接连接数据库操作表格,然后是机房个人重构中应用的操作实体,在其中还利用了一个很重要的帮助类:SQLHelper. 在这个转变中,已经逐步由面向过程转向面向对象,但在分层操作实体的过程中,由于数据库的设计不很完美,有时候需要修改数据库设计,或者需要更改实体.每次遇到这样的事儿,就脑袋疼,因为数据库和实体必须要对应起来,不然问题就越改越大了. 那么怎样解决这一问题呢?最近学习了一个EF

1.查询生命周期 在进入正题时候,我们先来了解EF Core查询的生命周期. 1.1LINQ查询会由Entity Framework Core处理并生成给数据库提供程序可处理的表示形式(说白了就是生成给数据库可识别数据形式). ●发送的查询结果(查询表示形式)会被缓存,以便每次执行查询时无需进行1.1中处理. 1.2查询结果(查询表示形式)会传递到数据库提供程序 ●数据库提供程序会识别出查询的哪些部分可以在数据库中求值.●查询的这些部分会转换为特定数据库的查询语言(例如,关系数据库的T-SQL)