blocks|key|268237|text|如果您在控制器中实现IDisposable，并在disposing方法中处理上下文，并在控制器构造函数中实例化新上下文，则应该是安全的，因为控制器是为每个请求实例化的。我不明白，但是，你为什么要这样做呢？您应该使用DI，或者使用context的一个静态实例来创建context工厂。如果不使用一个实例(为每个请求创建一个实例)，那么在某些情况下就会出现问题。未处理的context的问题是EF在context中缓存数据，如果context的某个其他实例更改了DB中已经缓存到另一个context中的内容，则会出现状态不一致的情况。在DI变得如此流行之前，我曾经在应用程序中的某个地方拥有一个上下文的静态实例，这比让每个请求创建自己的上下文要快得多，也更安全，但您需要实现状态检查代码，以确保到数据库的上下文连接是正常的……对于这个问题，有很多更好的解决方案，最好的方法是使用一些依赖注入框架。我建议将NuGet与MVCTurbine结合使用，它很容易设置，你可以通过Ninject添加它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|268238|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you implement IDisposable in your controller, and dispose context in disposing method, and instantiate new context in controller constructor, you should be safe as controller is instantiated for each request.
I don't see, however, why would you want to do that?
...
You should use DI, or make a context factory with one static instance of context. If you don't use one instance (you make one for each request) you are to have problems at some point. The problem with undisposed context is that EF caches data in context, and if some other instance of context changes something in DB that is already cached in another context - you have unconsistent state. Before DI became so popular, I used to have one static instance of context somewhere in application, and that is a lot faster and safer than having each request make its own context, but you need to implement state-checking code which makes sure that context connection to db is ok... There are a lot better solutions to this problem, and the best is to use some DI framework. I would recommend Ninject in combination with MVCTurbine, it is easy to set up and you can add it through NuGet.

blocks|key|265103|text|一种方法是订阅Application_BeginRequest事件，将DbContext注入到当前HttpContext和从HttpContext获取的Application_EndRequest中，然后进行处置。介于两者之间的任何东西(几乎都是：-)都可以从当前HttpContext中获取DbContext并使用它。是的，你应该把它处理掉。顺便说一下，除了其他有用的东西之外，你有什么理由不使用已经为你做了这件事的依赖注入框架吗？|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|265104|entityMap^0|7|O|24|M|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

One way would be to subscribe for the <code>Application_BeginRequest</code> event, inject the DbContext into the current HttpContext and in the <code>Application_EndRequest</code> fetch from the HttpContext and dispose. Anything in between (which is pretty much everything :-)) could fetch the DbContext from the current HttpContext and use it. And, yes, you should dispose it. And by the way is there any reason you don't use a DI framework which already does this for you among other useful things?

blocks|key|3173105|text|我会使用BeginRequest/EndRequest方法，这有助于确保当请求结束时，您的上下文被正确处理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3173106|protected+virtual+void+Application_BeginRequest()
{
++++HttpContext.Current.Items["_EntityContext"]+=+new+EntityContext();
}

protected+virtual+void+Application_EndRequest()
{
++++var+entityContext+=+HttpContext.Current.Items["_EntityContext"]+as+EntityContext;
++++if+(entityContext+!=+null)
++++++++entityContext.Dispose();
}|code-block|syntax|javascript|3173107|在你的EntityContext类中..。|3173108|public+class+EntityContext
{
++++public+static+EntityContext+Current
++++{
++++++++get+{+return+HttpContext.Current.Items["_EntityContext"]+as+EntityContext;+}
++++}
}|3173109|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I would use the BeginRequest/EndRequest method, this helps ensure that your context is disposed of properly when the request is over with.

<pre><code>protected virtual void Application_BeginRequest()
{
 HttpContext.Current.Items["_EntityContext"] = new EntityContext();
}

protected virtual void Application_EndRequest()
{
 var entityContext = HttpContext.Current.Items["_EntityContext"] as EntityContext;
 if (entityContext != null)
 entityContext.Dispose();
}
</code></pre>

And in your EntityContext class...

<pre><code>public class EntityContext
{
 public static EntityContext Current
 {
 get { return HttpContext.Current.Items["_EntityContext"] as EntityContext; }
 }
}
</code></pre>

blocks|key|2959293|text|这里的滑动坡度具有不一致的状态。如果你的应用程序上有多个用户，并且他们有可能同时更改数据，那么如果你只保留一个上下文，你可能会遇到数据完整性的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2959294|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The slippery slope here is having inconsistent state. If you're app is going to have multiple users on it, and they have the potential to change data concurrently then you might start running into problems with data integrity if you keep a single context.

blocks|key|3173149|text|我知道这不是一个最近的问题，但无论如何我都会发布我的答案，因为我相信有人会发现它很有用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3173150|可能和其他许多人一样，我遵循了公认答案中提到的步骤。耶，它起作用了。然而，，有一个问题：|offset|length|style|BOLD|3173151|方法BeginRequest()和EndRequest()+在每次发出请求时都会触发，但不仅是针对aspx页面，而且是针对所有静态内容！也就是说，如果您使用上面提到的代码，并且页面上有30个图像，那么您将重新实例化dbcontext+30次！|3173152|这个问题的解决方案是使用包装类来检索上下文，如下所示：|3173153|internal+static+class+ContextPerRequest
{
++++++internal+static+DB1Entities+Current
++++++{
++++++++++get
++++++++++{
++++++++++++++if+(!HttpContext.Current.Items.Contains("myContext"))
++++++++++++++{
++++++++++++++++++HttpContext.Current.Items.Add("myContext",+new+DB1Entities());
++++++++++++++}
++++++++++++++return+HttpContext.Current.Items["myContext"]+as+DB1Entities;
++++++++++}
++++++}
+}|code-block|syntax|javascript|3173154|然后用来处理|3173155|protected+void+Application_EndRequest(object+sender,+EventArgs+e)
{
+++var+entityContext+=+HttpContext.Current.Items["myContext"]+as+DB1Entities;
+++if+(entityContext+!=+null)+
++++++entityContext.Dispose();
}|3173156|此修改可确保每个请求仅实例化和处置一次上下文，且仅在需要时执行。每次选择的答案都会实例化上下文。|3173157|注意：+DB1Entities是从DbContext派生的(由VS生成)。您可能希望使用您的上下文名称来更改它;)|3173158|dbcontext注2:在本例中，我只使用了一个。如果您需要使用多个，则需要根据需要修改此代码。不要认为这是世界问题的终极解决方案，因为它肯定不是最终产品。这只是为了给出一个提示，如何以一种非常简单的方式实现它。|3173159|注意3:相同的方法也可以在不同的情况下使用，例如，当您想要共享SqlConnection的实例或任何其他...这个解决方案不是DbContext对象所独有的，也不是实体框架所独有的。|3173160|entityMap^0|0|Y|3|0|U|5|0|0|0|0|0|0|0|3|0|O|2A|0|0|2J|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@$D|16|E|17|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|18|8|@$D|19|E|1A|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1B|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1C|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|1D|8|@]|9|@]|A|$]]|$1|S|3|T|5|N|7|1E|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|1F|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1G|8|@$D|1H|E|1I|F|G]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1J|8|@$D|1K|E|1L|F|G]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1M|8|@$D|1N|E|1O|F|G]]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]]|13|$]]

I know this is not a recent question, but I'll post my answer anyway, because I believe someone may find it useful. 

As probably many others, I followed the steps mentioned in the accepted answer. Yay, it works. HOWEVER, there's one catch:

Methods BeginRequest() and EndRequest() fire each time a request is made, but not only for aspx pages, but for ALL STATIC CONTENT! That said, if you use the code mentioned above and you have on your page let's say 30 images, you're re-instantiating your dbcontext 30 times!

The solution for this is to use a wrapping class for retrieving the context, something like this:

<pre><code>internal static class ContextPerRequest
{
 internal static DB1Entities Current
 {
 get
 {
 if (!HttpContext.Current.Items.Contains("myContext"))
 {
 HttpContext.Current.Items.Add("myContext", new DB1Entities());
 }
 return HttpContext.Current.Items["myContext"] as DB1Entities;
 }
 }
 }
</code></pre>

And then for disposing 

<pre><code>protected void Application_EndRequest(object sender, EventArgs e)
{
 var entityContext = HttpContext.Current.Items["myContext"] as DB1Entities;
 if (entityContext != null) 
 entityContext.Dispose();
}
</code></pre>

This modification ensures that you instantiate and dispose your context only once per request and only when needed. Selected answer instantiates context every single time.

Note: DB1Entities is derived from DbContext (generated by VS). You would probably want to alter it with your context name ;)

Note 2: in this example I'm working with just one dbcontext. If you need to work with multiple, you would need to modify this code according to your needs. Don't take this as some ultimate solution to world problems, because it certainly isn't a final product. It is meant just to give a hint, how it may be achieved in a very easy way.

Note 3: Same approach can be used in different situations as well, for instance when you'd like to share an instance of SqlConnection or any other... This solution isn't exclusive to DbContext object, nor to Entity framework.

blocks|key|266591|text|查德·莫兰回答的小补充。它的灵感来自walther的笔记。为了避免静态内容的上下文初始化，我们应该检查当前的路由处理程序(本例仅针对MVC)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|266592|protected+virtual+void+Application_BeginRequest()
{
++var+routeData+=+RouteTable.Routes.GetRouteData(new+HttpContextWrapper(this.Context));
++if+(routeData+!=+null+&&+routeData.RouteHandler+is+MvcRouteHandler)
++{
++++HttpContext.Current.Items["_EntityContext"]+=+new+EntityContext();
++}
}|code-block|syntax|javascript|266593|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Small addition for Chad Moran answer. It is inspired by walther notes. To avoid context initialization for static content we should check current route handler (this example only for MVC):

<pre class="lang-cs prettyprint-override"><code>protected virtual void Application_BeginRequest()
{
 var routeData = RouteTable.Routes.GetRouteData(new HttpContextWrapper(this.Context));
 if (routeData != null &amp;&amp; routeData.RouteHandler is MvcRouteHandler)
 {
 HttpContext.Current.Items["_EntityContext"] = new EntityContext();
 }
}
</code></pre>

Apologies if this has already been answered, but how do you guarantee one Entity Framework DbContext per request if you are not using an IOC container? (The answers I've come across so far deal with IOC container solutions.)

It seems like most solutions hook into the <code>HttpContext.Current.Items</code> dictionary, but how do you guarantee disposal of the DbContext when the request is finished? (Or is disposal not absolutely necessary with an EF <code>DbContext</code>?)

Edit

I'm currently instantiating and disposing my DbContext in my controllers, but I also have several separate instantiations of my DbContext in ActionFilters and my MembershipProvider (and I just noticed, also a couple validators). So, I thought it might be a good idea to centralize instantiation and storage of my DbContext to reduce overhead.

One DbContext per request in ASP.NET MVC (without IOC container)

数据完整性

数据库

容器

路由

如果这个问题已经回答了，很抱歉，但是如果您不使用IOC容器，如何保证每个请求都有一个实体框架DbContext？(到目前为止，我遇到的答案都与IOC容器解决方案有关。)似乎大多数解决方案都与HttpContext.Current.Items字典挂钩，但是如何保证在请求完成时处理DbContext呢？(或者，对于EF D...

问ASP.NET MVC中的每个请求一个DbContext (没有IOC容器)
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.NET MVC中的每个请求一个DbContext (没有IOC容器)EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问ASP.NET MVC中的每个请求一个DbContext (没有IOC容器)
EN