EntityFramework优缺点

2015-12-9 14:39:22 次浏览 分类:软件开发

改变在现有系统使用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更新的开销大么? 
• 大多数DB重新计算索引。 这是一个问题关系到DBA。 

 

当我们使用EF为700-800KB的XML文件来更新XML列,我们收到了有关SQL Server的tempdb一个异常。 什么造成的吗? 
• 可能涉及到数据库如何用临时表来更新XML的内容。

   应该和DBA检查你的数据库,你也许需要增加您的tempdb数据库的大小。 
• 在一般情况下, 大的对象,如XML使在GC的Large Object Heap内存的压力,你应该考虑迁移到.NET 4.5版本的GC大型对象堆碎片整理特性。 
• 你可以考虑来存储XML为byte [],它可以被压缩(XML不是一种非常经济的格式)。

 

使用EF与ADO.Net的开销? 
• DataReader的结果变换到对象的开销,从LINQ编译SQL查询的开销。

   您将有相同的开销,甚至更多,如果您尝试建立你自己的ORM框架。 不这样做! 
• 抽象层的开销, 它取决于他们用EF所做的事情。 
• 一般而言,您应该组合替代继承,避免它有一个更大的开销。

推荐知识

  • 软件开发流程

    软件开发流程需求分析1.相关系统分析员向用户初步了解需求,然后用word列出要开发的系统的大功能模块,每个大功能模块有哪些小功能模块,对于有些需求比较明确相关的界面时,在这一步里面可以初步定义好少量的界面。2.系统分析员深入了解和分析需求,根据自己的经验和需求用WO…

    2015-7-23 9:46:42
  • 定制软件的四大优点

    定制软件在很多时候不仅是必要的,而且是必须的。所以深入了解一些定制软件方面的知识对于每个公司的决策层来说是非常有必要的。通常大家认为定制软件的优点主要体现在以下几个方面:1.针对性强 定制软件因为是量身定做的,所以针对性非常强,这也是定制软件最大的优点。因为每…

    2015-7-22 9:34:26
  • 软件开发需要学习什么

    一、重视基础课的学习,计算机虽然是高科技的象征,但又受到其它专业发展的制约。二、理论联系实践,学习编写程序,不仅要领悟老师的各种知识点,多看教材,还要结合课程重视上机的练习。

    2014-11-17 9:47:39
  • 面向对象编程思想,面向对象的世界观

    它是从现实世界中客观存在的事物(即对象)出发来构造软件系统,并在系统构造中尽可能运用人 类的自然思维方式,强调直接以问题域(现实世界)中的事物为中心来思考问题,认识问题,并根据这些事物的本质特点,把它们抽象地表示为系统中的对象,作为 系统的基本构成单位(而不…

    2014-11-6 10:58:43