渴望，懒惰，明确装载在EF6 [英] Eager , Lazy and explicit loading in EF6

问题描述

我已阅读本教程这的文章，但我不明白究竟使用各负荷类型。

我解释

我有这样的POCO：

 公共部分类dpc_gestion 
 {
公共dpc_gestion（）
 {
 this.ass_reunion_participant =新的HashSet< ass_reunion_participant>（） ; 
 this.dpc_participant =新的HashSet< dpc_participant>（）; 
 this.dpc_reunion =新的HashSet< dpc_reunion>（）; 
} 
 
公众诠释dpc_id_pk {搞定;组; } 
公众可空< INT> dpc_id_gdp_fk {搞定;组; } 
公众可空< INT> dpc_id_theme {搞定;组; } 
公众诠释dpc_id_animateur_fk {搞定;组; } 
公众可空<&System.DateTime的GT; dpc_date_creation {搞定;组; } 
公众可空<&System.DateTime的GT; dpc_date_fin {搞定;组; } 
公众可空<&System.DateTime的GT; dpc_date_engag_anim {搞定;组; } 
公众可空<布尔> dpc_flg_let_engag_anim {搞定;组; } 
公众可空<布尔> dpc_flg_fsoins_anim {搞定;组; } 
公共虚拟的ICollection< ass_reunion_participant> ass_reunion_participant {搞定;组; } 
公共虚拟theme_dpc theme_dpc {搞定;组; } 
公共虚拟gdp_groupe_de_pair gdp_groupe_de_pair {搞定;组; } 
公共虚拟的ICollection< dpc_participant> dpc_participant {搞定;组; } 
公共虚拟的ICollection< dpc_reunion> dpc_reunion {搞定;组; } 
} 
  

我理解这一点：

1. 对于延迟加载：因为负载是懒惰的，如果我叫了dbset dpc_gestion 所有的导航属性的不会加载。这种类型的负载是在性能和​​响应能力是最好的。它是默认启用的，如果我想重新启用它，我必须设置：

     context.Configuration.ProxyCreationEnabled = TRUE; 
    context.Configuration.LazyLoadingEnabled = TRUE; 
     




2. 对于预先加载
   这是不懒惰：它加载的所有导航属性当我加载 dpc_gestion 。导航属性可以使用包含方法被加载。要启用此负载类型：

     context.Configuration.LazyLoadingEnabled = FALSE; 
     




3. 对于明确的装载
   它像在预先加载，但是我们使用加载方法，而不是包含。

所以我想知道：

1. 如果这个小小的简历真的吗？


2. 如果这是真的，渴望和明确加载之间的区别是什么？


3. 如果我使用延迟加载我呼吁例如 dpc_gestion.dpc_participant ，做导航性能负载？或者我会得到一个异常？


4. 有没有情况下，当预先加载或明确的装载比延迟加载的性能和响应能力更好？

感谢

< DIV CLASS =h2_lin>解决方案

如果这个小的简历是真的吗？

是

如果这是真的，什么是渴望和明确加载的区别？

预先加载为延迟加载相反，但明确载入类似于延迟加载 除了您明确检索代码中的相关数据;当您访问导航属性不会自动发生。您可以通过获取一个实体对象状态管理器项，并要求收藏的 Col​​lection.Load 法或 Reference.Load 对于持有单一的实体属性的方法。

从的技术博客：

预先加载：

预先加载是延迟加载这是在相反：该过程
用在查询中明确要求的对象
一起装入一组特定的相关对象的

显式加载：

显式加载的定义是：当目标通过查询返回，不同时装载
相关对象。默认情况下，它们是
不加载，直到使用在
导航属性Load方法有明确要求。

和：

如果我使用延迟加载和我打电话例如 dpc_gestion.dpc_participant ，请问导航性能负载？或者我会得到一个异常？

您没有得到任何异常，导航性能应负载

有没有时预先加载或明确加载较好
比的性能和响应延迟加载的情况？

预先加载通常是更有效的，当你需要对主表的所有检索的行相关数据。并且，当关系不是太大，预先加载将是很好的做法，以减少对服务器进一步查询。但是，当你知道你将不需要的属性立刻然后点击延迟加载也许是不错的选择。而且也渴望加载在您的数据库环境将被设置，并且延迟加载未能举行了一个情况是不错的选择。例如，考虑以下内容：

 公开名单<拍卖与GT; GetAuctions（）
 {
使用（DataContext的DB =新的DataContext（））
 {
返回db.Auctions.ToList（）; 
} 
} 
  

调用此方法后，您不能加载相关实体懒洋洋因为分贝配置，因此在预先加载将在这里是一个更好的选择。

还有一点需要注意的是：延迟加载会产生几个SQL请求，而预先加载加载一个请求数据。 预先加载也是一个不错的选择来解决的 n + 1个选择问题在奥姆斯。
有一个看看这篇文章：什么是N + 1选择问题？

I have read this tutorial and this article but I don't understand exactly the use of each loading type.

I Explain

I have this POCO :

public partial class dpc_gestion
{
    public dpc_gestion()
    {
        this.ass_reunion_participant = new HashSet<ass_reunion_participant>();
        this.dpc_participant = new HashSet<dpc_participant>();
        this.dpc_reunion = new HashSet<dpc_reunion>();
    }

    public int dpc_id_pk { get; set; }
    public Nullable<int> dpc_id_gdp_fk { get; set; }
    public Nullable<int> dpc_id_theme { get; set; }
    public int dpc_id_animateur_fk { get; set; }
    public Nullable<System.DateTime> dpc_date_creation { get; set; }
    public Nullable<System.DateTime> dpc_date_fin { get; set; }
    public Nullable<System.DateTime> dpc_date_engag_anim { get; set; }
    public Nullable<bool> dpc_flg_let_engag_anim { get; set; }
    public Nullable<bool> dpc_flg_fsoins_anim { get; set; }
    public virtual ICollection<ass_reunion_participant> ass_reunion_participant { get; set; }
    public virtual theme_dpc theme_dpc { get; set; }
    public virtual gdp_groupe_de_pair gdp_groupe_de_pair { get; set; }
    public virtual ICollection<dpc_participant> dpc_participant { get; set; }
    public virtual ICollection<dpc_reunion> dpc_reunion { get; set; }
}

I understood this :

1. For Lazy loading : because the load is lazy, if I call the dbset dpc_gestion all navigation properties won't be loaded. This type of loading is the best in performance and responsiveness. It is enabled by default and If I'd like to re-enable it I have to set :

   context.Configuration.ProxyCreationEnabled = true;    
   context.Configuration.LazyLoadingEnabled = true;
   

2. For the eager loading It is not lazy: it loaded all navigation properties when I load dpc_gestion. The navigation properties can be loaded using include method. To enable this loading type :

   context.Configuration.LazyLoadingEnabled = false;
   

3. For the explicit loading It is like the eager loading but we use Load method instead of include.

So I'd like to know :

1. If this small resume is true ?
2. If it is true, what is the difference between eager and explicit loading?
3. If I Use lazy loading and I call for example dpc_gestion.dpc_participant, does the navigation properties loads?or I will get an exception?
4. Is there a case when eager loading or explicit loading were better than lazy loading in performance and responsiveness?

Thanks

解决方案

If this small resume is true ?

Yes.

If it is true, what is the difference between eager and explicit loading?

Eager loading is the opposite of Lazy loading but Explicit loading is similar to lazy loading, except that: you explicitly retrieve the related data in code; it doesn't happen automatically when you access a navigation property. You load related data manually by getting the object state manager entry for an entity and calling the Collection.Load method for collections or the Reference.Load method for properties that hold a single entity.

From techblog:

Eager Loading :

Eager loading is the opposite of Lazy loading which is : The process of loading a specific set of related objects along with the objects that were explicitly requested in the query.

Explicit Loading :

Explicit loading is defined as : when objects are returned by a query, related objects are not loaded at the same time. By default, they are not loaded until explicitly requested using the Load method on a navigation property.

And:

If I Use lazy loading and I call for example dpc_gestion.dpc_participant, does the navigation properties loads?or I will get an exception?

You don't get any exception and the navigation properties should loads.

Is there a case when eager loading or explicit loading were better than lazy loading in performance and responsiveness?

Eager loading is typically more efficient when you need the related data for all retrieved rows of the primary table. And also when relations are not too much, eager loading will be good practice to reduce further queries on server. But when you know that you will not need a property instantly then lazy loading maybe a good choice. And also eager loading is a good choice in a situation where your db context would be disposed and lazy loading could not take place anymore. For example consider the following:

public List<Auction> GetAuctions()
{
    using (DataContext db = new DataContext())
    {
        return db.Auctions.ToList();
    }
}

After calling this method, You cannot load the related entity lazily because the db is disposed and so the Eager Loading would be a better choice here.

One more thing to note is: Lazy loading will produce several SQL request while Eager loading load data with one request. Eager loading is also a good choice to solve the n+1 selects issue in ORMs. Have a look at this post: What is the n+1 selects issue?

这篇关于渴望，懒惰，明确装载在EF6的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！