Entity Framework 基础（一）：参考资料、三种模式(DataBase First/Model First/CodeFirst)、应用场景、优缺点

最新推荐文章于 2024-09-10 14:01:41 发布

.NET跨平台

最新推荐文章于 2024-09-10 14:01:41 发布

阅读量1.4k

点赞数 2

分类专栏： ADO.NET 和 Entity Framework 文章标签： database hibernate

原文链接：https://blog.csdn.net/WuLex

版权

ADO.NET 和 Entity Framework 专栏收录该内容

48 篇文章 8 订阅

订阅专栏

一、参考资料（简介）

本系列，将介绍实体框架EF（entity framework）。

参考：https://www.cnblogs.com/wangboy91/p/6047905.html

什么是EF框架？

全称EntityFramework 官方点的解释是Entity Framework是ADO.NET 中的一套支持开发面向数据的软件应用程序的技术,是微软的一个ORM框架。

ORM框架是什么东西?

Object Relational Mapping 翻译过来就是对象关系映射。如果你无法理解这个东西。我只能告诉你去百度了。反正我刚开始的也不太明白。下面有个图方便我们理解
在这里插入图片描述
在整个领域比较常用的有：Hibernate，iBATIS，mybatis这些在java生态里面应用的orm框架，这些框架当然也有C#版本的。但是作为微软的亲儿子C# 系列肯定采用EF框架了毕竟强大的linq让我太喜欢了。在ios开发领域中有Core Data 等和安卓的ormlite等，这些都是orm框架。

1、官网

https://docs.microsoft.com/zh-cn/ef/

官网里面，包含了最详细最原始的文章，中文博客上的东西，基本都是从官网Copy+变形过来。我们要看，就看最好的，我们要做，就做最好的。
在这里插入图片描述

2、中文博客

https://www.cnblogs.com/wdcwy/p/6412944.html

https://www.cnblogs.com/wujingtao/p/5401113.html

https://www.cnblogs.com/xuf22/articles/5513283.html

https://blog.csdn.net/xiongmeiqin/article/details/80196089

二、EF框架的三种模式

DataBase First 数据库优先，传统的表驱动方式创建EDM，然后通过EDM生成模型和数据层代码。除生成实体模型和自跟踪实现模型，还支持生成轻型DbContext。简历理解就是先设计数据库，创建好数据库映射成对象和上下文。

Model First 模型优先，先创建EDM模型，再生成DDL数据库脚本和模型和数据层代码。除生成实体模型和自跟踪实现模型，支持生成轻型DbContext。简单理解就是设计EDM模型然后生成到数据库和创建对象和上下文。

CodeFirst 代码优先，手动创建POCO模型，数据层DbContext及映射关系，通过Database.SetInitializer生成数据库，这种方式较灵活，但是需要手动定义实体模型和关系映射。简单理解就是自己写好实体对象和映射关系，最后通过命令生成到数据库中去。

三、Entity Framework应用场景

https://blog.csdn.net/wulex/article/details/79286310

四、Entity Framework的优缺点

转https://blog.csdn.net/wulex/article/details/79286310

Entity Framework是MS提供的一个ORM框架，它旨在为小型应用程序中数据层的快速开发提供便利。

nuget上185W多的下载量，说明.Net开发人员还是比较喜欢用EF的。但是EF在提供了便利性的同时也有许多缺点，以下就是我认为不应该应用EF的场景：

非SQL Server数据库且无该数据库的DataProvider
高性能要求。在进行一些复杂查询的情况下，EF的性能表现不太好，而开发人员又无法控制SQL语句的生成
高安全性要求。有时候DB用户仅仅具有EXEC的权限，而EF自动生成的类又不好用，还是需要自己来写。

一些大中型企业应用往往具有以上几种情况，此时就不适合使用EF了。

至于使用什么ORM，我个人认为NHibernate配置起来太麻烦，如果没什么太特殊的要求，可以试一下ServiceStack.OrmLite能不能满足需求。或者直接上ADO.Net

如果非要使用EF，建议使用EF最新的稳定发布版本（支持DbContext+Code first方式开发）。然后读一下《Programming Entity Framework Code First》和《Programming Entity Framework DbContext》这两本书（目前无中文版）。使用DbContext+Code first POCO+Repository模式，这样既可以保证EF被Repository隔离，又可以保证可测试性，还能在需要更换ORM框架甚至是换成ADO.Net时少改一点代码。

提供示例代码下载（.Net 4+EF5）

示例代码中有POCO和EF的Configurations，把EF相关的Configurations单独拿出来保证了DB Model的纯洁性。在这里大体摘一点东西给大家看看

首先是数据库结构，我使用的是Code first，在第一次有实际的数据库操作的时候会自动生成数据库，生成后的数据库结构如下图：
在这里插入图片描述

数据库的生成策略在EFContext类的静态构造里面：

static EFContext()
{
   // 指定数据库生成策略为不存在时生成
    // 还可以指定为：
    // DropCreateDatabaseAlways（总是删除原有数据库重建）
    // DropCreateDatabaseIfModelChanges（数据库模型改变后删除原有数据库重建）
    Database.SetInitializer<EFContext>(new CreateDatabaseIfNotExists<EFContext>());
}

Album表的Configuration设置：

public class AlbumConfiguration : EntityTypeConfiguration<Album>
{
    public AlbumConfiguration()
    {
        // 指定数据表名
        ToTable("dbo.Album");
 
        // 设定主键
        HasKey(x => x.Id);
 
        // 设定数据列名及其它属性
        Property(x => x.Id).HasColumnName("Id").HasDatabaseGeneratedOption(DatabaseGeneratedOption.Identity).IsRequired();
        Property(x => x.AlbumName).HasColumnName("AlbumName").IsRequired().HasMaxLength(50);
        Property(x => x.ArtistId).HasColumnName("ArtistId").IsRequired();
 
        // 设置外键约束
        HasRequired(foreignKeyTable => foreignKeyTable.Artist)
            .WithMany(primaryKeyTable => primaryKeyTable.Albums)
            .HasForeignKey(foreignKeyTable => foreignKeyTable.ArtistId);
 
        // 设置多对多关联
        HasMany(thisTable => thisTable.Tags)
            .WithMany(anotherForeignKeyTable => anotherForeignKeyTable.Albums)
            .Map(relationTable => relationTable
                .MapLeftKey("TagId")
                .MapRightKey("AlbumId")
                .ToTable("AlbumTags")
            );
    }
}

重写EFContext类中的OnModelCreating函数，使用我们自定义的Configurations：

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);
 
    // 设定数据库生成配置
    modelBuilder.Configurations.Add(new ArtistConfiguration());
    modelBuilder.Configurations.Add(new AlbumConfiguration());
    modelBuilder.Configurations.Add(new TagConfiguration());
}

Repository模式这里我就不多说了，具体看AbstractDbAccessor项目中的内容，EF的Repository实现在ConcreteDbAccessor项目EntityFramework目录下的EFDbAccessor和Repository目录

EntityFramework优缺点

Entity Framework 是微软推荐出.NET平台ORM开发组件, 现在已放源代码. 以下我们来讨论一下优缺点和一些问题, 以下简称EF. 有兴趣可查询官网的Entity Framework 6 RoadMap.

EntityFramework

高层视图：

改变在现有系统使用EntityFramework的优势是什么？

All -in-1框架的类映射表，需要编写映射代码, 并且是很难维护的。
可维护性，易于理解的代码，无需创造大的数据访问层。
提供LINQ查询数据库，这需要从初级开发人员不太了解SQL。
EF可以用作用于数据服务和OData Service的基础设施。

什么的情况下，不建议使用EF呢?

实时的应用程序。
只能通过存储过程访问数据库。 EF的优势是：跟踪实体状态Change时，不仅仅在存储过程上.（即使EF确实对存储过程支持有限的）。
频繁插入操作（Insert）, 并且EF不支持大数据Bulk 插入。
频繁更新操作，更新的目标主要是当多行（用一个单值）

例如：UPDATE 表名 SET ColumA = 10 Where ColumnB =？ 这种更新操作更好的使用的ExecuteNonQuery（也可从Context上下文或直接从Ado.Net）。

反范式的表设计和高性能查询。 EF产生查询，他们是难以维护的，它并不能很好地支持映射到不规范的表。
对程序有非常的性能要求, 需要对每个查询进行监控.

我们要在加载所有数据到内存中，建议使用实体框架？我们应该期待什么样的问题呢？

加载的所有实体将需要许多查询和大量的时间。
内存开销。
会有延迟，因为EF需要跟踪实体的变化的和大Collection对象的处理。
EF的Context上下文不是线程安全的，你不应该在整个Service上使用一个Context上下文。
如果你打算这样做，使用EF加载实体，但并不管理它们. (Detach the entities从context)。
不使用的上下文Context对象作为一个缓存对象（用于分布式的情况下). 它不是线程安全的，有一些开支和不遵循分散关注(Separation of Concern)的设计。更好的办法是设计缓存API，如AppFabric缓存。

技术层面：

内存泄漏：

我们有这样一个场景，每10秒我们打开Context上下文获取一个单表，并关闭它。 “using (entities context = new entities(_connection)) {… ”

经过一段几个小时，这引起了内存泄漏。

我建议你检查内存泄漏，以确保它是从EF是根源。 EF是一个开源的，所以现在可以报告任何内存泄漏并修正它。
使用Profiler的VMMap，以便跟踪泄漏的源头。

在这种情况下，我们应该保持`Context`一直打开？

这其实并不重要，因为查询仍然会执行。然而，这是最好关闭Context下，所以缓存的实体将垃圾回收，否则Context和缓存的实体将在GC中升级到第二代，并且会被困在那里的持续一段时间。
不要为WCF每个请求创建一个Context上下文对象。
推荐的做法是为每次操作创建的Context对象，因为实体Item一旦被被添加到数据库后就已经过时了，可能会导致数据损坏或重复的Item

EDMX的大小有影响吗？

EDMX影响的大小，因为所有的EDMX数据加载到内存中创建Context上下文。
EDMX被加载到内存中，解析与映射在AppDomain中创建和缓存。您可以关闭并重新打开Context，它没有影响已缓存EDMX映射。

非常多的表

如果所有的表放在单个的EDMX或分别存放于几个EDMX文件之间？
如何能管理的EDMX中大量的实体？例如，如何可以找到它们？

在设计器中修改一个特定的表？

如果拆分之间edmx文件，你可以不连接实体的导航性能。
你应该建立自己的模型，根据您的实体模型设计 - 如果你有一组是独立的实体，他们可以在不同的EDMX模型。
EDMX文件处理数百个实体类型。如果实体类型的数量超过1000家，我会考虑到的几个Edmxs（分开和重新审视自己的实体模型设计，因为成千上万的实体类型的一个系统似乎太多）。
在VS 2012，以设计器的增强分解功能和着色等，请参阅以下链接。
EF设计器有一些改进，如着色区分实体组的实体。
也有第三方实体的设计器，可能会得到更好的用户体验。
请记住 - EF是一个开源的，你可以给他们的要求，甚至贡献自己的增加，所以在EDMX设计器探索很有趣的。
你应该按每个域/服务来拆分edmx文件到不同EDMX文件。

表之间关系

Lazy与No Lazy模式？

在分布式情况下Lazy代码是魔鬼。
如果他们需要一组表中的数据，然后使用Include，否则，你可以使用Lazy Load模式

“Include”命令加载整个表或ObjectSet原始记录？

Include加载是相关实体的列。 EF不使用 * 查询.

如何使用EF执行批量插入/更新操作？

做不到这一点，你需要使用原始的SQL语句来实现。

当一个实体被标记为已修改，EF更新的所有列？

它不更新所有的列，除非你正在使用分布式的应用程序与Self-Tracking。 “正常”实现下EF只更新修改列。 Self-Tracking不跟踪的已更新的属性，它标志着的所有属性已更新。您可以编辑Self-Tracking，并修复它，如果需要的话。
您可以附加一个SP以实现自定义的逻辑。
您可以更改T4模板的文件，在Self-Tracking下以保持所有原始值。

整个RAW更新的开销大么？