在LINQ to Entities中实例化上下文 [英] Instantiating a context in LINQ to Entities

问题描述

$ p

第一个是这样的，你可以找到它，所以我看到程序员在他们的代码中创建实体上下文时遇到的两种不同的方式。 MSDN代码示例：

  public void DoSomething（）{
 using（TaxableEducationEntities context = new TaxableEducationEntities（））{ 
 //业务逻辑和任何其他
} 
} 
  

第二种是将某些类中的私有属性创建为封装业务逻辑的类。所以你会有这样的：

  public class Education_LINQ {
 
 private TaxableEducationEntities context = new TaxableEducationEntities ）; 
 
 public void DoSomething（）{
 var result = from a in context.luAction 
 select a; 
 
 //业务逻辑和任何其他
} 
} 
  

哪种方式更有效率？假设你有两个方法，一个叫做DoSomething1（），另一个叫DoSomething2（），这两个方法都使用using语句来打开上下文并且做任何事情。您是否一个接一个地调用一个方法，是否会有任何多余的开销，因为基本上两个方法都创建上下文，然后在完成后将其清理掉？相对于在类对象被实例化时只创建一个私有属性，然后在对象超出范围时又被清除？

解决方案

每次创建一个新的ObjectContext都会涉及一些开销。所涉及的开销基本上是将元数据从全局缓存复制到与特定ObjectContext相关的元数据。

这个开销相对较小，因此经常不值得担心，特别是当您考虑使用模式中固有的额外安全性。

对于我，您选择的选项取决于以下事项：

1. 您的
   包装类可能有多长时间？如果它长期存在
   ，ObjectContext可能会
   增长，以保持很多实体
   随着时间的推移而减慢。所以一个新的
   ObjectContext每次都可能是一个
   的好主意。


2. 是否调用
   方法在你的包装类
   上同步？ ObjectContext
   类本身不是线程安全的，所以如果
   你使用第二个模式，你需要
   ，以确保你的包装类/
   仓库是线程安全如果你
   期望多个线程调用它。


3. 方法基本上是
   无关系吗？如果是这样，如果他们在方法之间共享一个上下文，可能会产生意想不到的副作用。

一般来说，我的建议是，如果方法是无状态的，也就是说，为每个方法忘记一个新的上下文可能是一个好主意。

如果你有一个相对较短的状态状态或某事，那么也许一个共享上下文是一个更好的主意。

更新：我花了时间把更完整的答案

I've seen two different manners that programmers approach when creating an entity context in their code.

The first is like such, and you can find it all over the MSDN code examples:

public void DoSomething() {
     using (TaxableEducationEntities context = new TaxableEducationEntities()) {
          // business logic and whatever else
     }
}

The second is to create the context as a private attribute in some class that encapsulates your business logic. So you would have something like:

public class Education_LINQ {

        private TaxableEducationEntities context = new TaxableEducationEntities();

        public void DoSomething() {
            var result = from a in context.luAction
                         select a;

            // business logic and whatever else
        }
}

Which way is more efficient?

Assume that you have two methods, one called DoSomething1() and another called DoSomething2(), and both methods incorporate the using statement to open the context and do whatever with it. Were you to call one method after the other, would there be any superfluous overhead going on, since essentially both methods create the context and then clean it up when they're done? As opposed to having just one private attribute that is created when a class object is instantiated, and then in turn cleaned up when the object goes out of scope?

解决方案

Creating a new ObjectContext each time does involve 'some' overhead. Essentially the overhead involved is copying metadata from a global cache into metadata associated with the specific ObjectContext.

This overhead is relatively minor, so often it is not worth worrying about, especially when you consider the extra safety inherent in the using pattern.

For me which option you choose depends upon things like:

1. How long lived is your wrapping class likely to be? If it lives for a long time the ObjectContext might grow to hold a lot of entities slowing down over time. So a new ObjectContext each time might be a good idea.
2. Are calls to the methods on your wrapping class synchronized? The ObjectContext class itself is not threadsafe so if you use the second pattern you need to make sure your wrapping class / repository is thread safe if you expect multiple threads to call it.
3. Are the methods essentially unrelated? If so you might get unexpected side-effects if they share one context between the methods.

In general my recommendation is that if the methods are stateless, i.e. fire and forget a new context for each method is probably a good idea.

If however you have a relatively short lived stateful form or something then maybe a shared context is a better idea.

UPDATE: I've taken the time to put together a more complete answer

这篇关于在LINQ to Entities中实例化上下文的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！