实体框架 - 我应该如何实例化我的“实体"?目的 [英] Entity Framework - How should I instance my "Entities" object

问题描述

我是 Entity Framework 和 ASP.Net MVC 的新手，主要从教程中学习，对任何一个都没有深入的了解.(我确实有 .Net 2.0、ADO.Net 和 WebForms 方面的经验)

我目前的疑问来自我实例化我的实体对象的方式.

基本上我在我的控制器中这样做:

公共类 PostsController : Controller {私人 NorthWindEntities db = new NorthWindEntities();公共行动结果索引(){//在此处使用 db 对象，从不显式关闭/处置它}}

我这样做是因为我在一些 MSDN 博客中发现它对我来说似乎足够权威，我认为这是一种正确的方法.
但是，我对此感到非常不安.虽然它为我节省了很多代码，但我已经习惯了:

使用 (NorthWindEntities db = new NorthWindEntities() {}

在每个需要连接的方法中，如果该方法调用其他需要它的方法，它会将 db 作为参数传递给它们.这就是在 Linq-to-SQL 存在之前我对连接对象所做的一切.

让我感到不安的另一件事是 NorthWindEntities 实现了 IDisposable，按照惯例，这意味着我应该将其称为 Dispose() 方法，而我没有.

您对此有何看法?
像我一样实例化实体对象是否正确?它是否应该通过为每个查询打开和关闭它们来处理其连接?
或者我应该使用 using() 子句显式处理它?<​​/p>

谢谢！

解决方案

Controller 本身实现了 IDisposable.因此，您可以重写 Dispose 并处置您在实例化控制器时初始化的任何内容(如对象上下文).

控制器只存在一个请求.因此，在一个动作中使用 using 并为整个控制器拥有一个对象上下文是完全相同的上下文数量:1.

这两种方法的最大区别在于，动作将在视图呈现之前完成.因此，如果您在操作内的 using 语句中创建 ObjectContext，则 ObjectContext 将在视图呈现之前被释放.因此，您最好在操作完成之前从上下文中阅读所需的任何内容.如果您传递给视图的模型是一些惰性列表，例如 IQueryable，您将在视图呈现之前释放上下文，当视图尝试枚举 IQueryable 时会导致异常.

相比之下，如果你在Controller初始化的时候初始化ObjectContext(或者写惰性初始化代码导致它在action运行时被初始化)并在Controller.Dispose中dispose ObjectContext，那么上下文仍然是渲染视图时左右.在这种情况下，将 IQueryable 传递给视图是安全的.Controller 将在视图渲染后不久被释放.

最后，如果我没有指出让您的控制器完全了解实体框架可能是一个坏主意，那我就失职了.考虑为您的模型和存储库模式使用单独的程序集，以使控制器与模型对话.谷歌搜索会出现很多.

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屋！