实体框架-我应如何在实例中引用我的“实体”目的 [英] Entity Framework - How should I instance my "Entities" object

问题描述

我是Entity Framework和ASP.Net MVC的新手，主要是从教程中学到的知识，而对这两种方法都不了解。 （我在.Net 2.0，ADO.Net和WebForms上确实有经验）

我当前的疑问来自于实例化实体对象的方式。

基本上，我在控制器中执行此操作：

 公共类PostsController：控制器{
 
私人NorthWindEntities db = new NorthWindEntities（）; 
 
 public ActionResult Index（）{
 //在此处使用db对象，永远不要显式关闭/处置它
} 
} 
  

我这样做是因为我在某个MSDN博客中找到了它，对我来说似乎足够权威，我认为这是正确的方法

但是，对此我感到非常不安。尽管它节省了很多代码，但我习惯于这样做：

 使用（NorthWindEntities db = new NorthWindEntities（）{ 
} 
  

在每个需要连接的方法中，如果该方法调用了其他方法， '它将需要它，它将db作为参数传递给他们。这就是我在Linq-to-SQL存在之前对连接对象进行所有操作的方式。

令我感到不安的另一件事是NorthWindEntities实现了IDisposable，按照惯例，这意味着我应该将其称为Dispose（）方法，而不是。

考虑这个问题吗？

在执行我的操作时是否实例化Entities对象是否正确？应该通过为每个查询打开和关闭它们来照顾它的连接吗？

还是应该这样做？我要使用using（）子句显式处理它？<​​/ p>

谢谢！

解决方案

控制器本身实现IDisposable，因此您可以覆盖Dispose和处理实例化控制器时初始化的所有内容（例如对象上下文）。

控制器仅存在一个请求。因此，在一个动作内部使用一个条件，并为整个控制器使用一个对象上下文是完全相同的上下文数量：1。

这两种方法之间的最大区别是该操作将在呈现视图之前完成。因此，如果您在操作内的using语句中创建ObjectContext，则ObjectContext将在呈现视图之前被处决。因此，最好在操作完成之前从所需的上下文中阅读任何内容。如果传递给视图的模型是诸如IQueryable之类的惰性列表，则您将在呈现视图之前处理上下文，从而在视图尝试枚举IQueryable时导致异常。

$ b相比之下，$ b

如果您在初始化Controller时初始化ObjectContext（或编写懒惰的初始化代码以使其在运行操作时被初始化）并在Controller.Dispose中处理ObjectContext，则上下文将呈现视图时仍然存在。在这种情况下，将IQueryable传递给视图是安全的。

最后，如果我不指出拥有您的控件可能不是一个好主意，那我将被解雇。控制器完全了解实体框架。考虑为模型和存储库模式使用单独的程序集，以使控制器与模型对话。 Google搜索会在此方面大有作为。

I'm a total newbie at Entity Framework and ASP.Net MVC, having learned mostly from tutorials, without having a deep understanding of either. (I do have experience on .Net 2.0, ADO.Net and WebForms)

My current doubt comes from the way I'm instancing my Entities objects.

Basically I'm doing this in my controllers:

public class PostsController : Controller {

    private NorthWindEntities db = new NorthWindEntities();

    public ActionResult Index() {
            // Use the db object here, never explicitly Close/Dispose it
    }
}

I'm doing it like this because I found it in some MSDN blog that seemed authoritative enough to me that I assumed this was a correct way.
However, I feel pretty un-easy about this. Although it saves me a lot of code, I'm used to doing:

using (NorthWindEntities db = new NorthWindEntities() {
}

In every single method that needs a connection, and if that method calls others that'll need it, it'll pass db as a parameter to them. This is how I did everything with my connection objects before Linq-to-SQL existed.

The other thing that makes me uneasy is that NorthWindEntities implements IDisposable, which by convention means I should be calling it's Dispose() method, and I'm not.

What do you think about this?
Is it correct to instance the Entities object as I'm doing? Should it take care of its connections by opening and closing them for each query?
Or should I be disposing it explicitly with a using() clause?

Thanks!

解决方案

Controller itself implements IDisposable. So you can override Dispose and dispose of anything (like an object context) that you initialize when the controller is instantiated.

The controller only lives as long as a single request. So having a using inside an action and having one object context for the whole controller is exactly the same number of contexts: 1.

The big difference between these two methods is that the action will have completed before the view has rendered. So if you create your ObjectContext in a using statement inside the action, the ObjectContext will have been disposed before the view has rendered. So you better have read anything from the context that you need before the action completes. If the model you pass to the view is some lazy list like an IQueryable, you will have disposed the context before the view is rendered, causing an exception when the view tries to enumerate the IQueryable.

By contrast, if you initialize the ObjectContext when the Controller is initialized (or write lazy initialization code causing it to be initialized when the action is run) and dispose of the ObjectContext in the Controller.Dispose, then the context will still be around when the view is rendered. In this case, it is safe to pass an IQueryable to the view. The Controller will be disposed shortly after the view is rendered.

Finally, I'd be remiss if I didn't point out that it's probably a bad idea to have your Controller be aware of the Entity Framework at all. Look into using a separate assembly for your model and the repository pattern to have the controller talk to the model. A Google search will turn up quite a bit on this.

这篇关于实体框架-我应如何在实例中引用我的“实体”目的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！