MVC EF上下文实例 [英] MVC EF Context Instances

问题描述

我很抱歉，如果我的问题看起来很笨，我已经尝试过Google搜索，没有找到我正在寻找的内容，所以任何建议都将不胜感激。

我很公平新的MVC的想法，我一直在做Web表单开发多年，但我想给别的东西尝试。

我正在使用实体框架（6）用于数据库连接，MVC4用于Web前端。

我的问题是，DB上下文实例应该如何处理。

我的控制器正在运行的Action代码是这个

  public ViewResult List（int buildingId）
 {
 var model = new Data.Model（）; 
 var query = from r in model.Rooms 
其中r.Building.Id == buildingId 
 select r; 
 / * 
 var q2 = model.Buildings.Where（b => b.Id == buildingId）.SelectMany（b => b.Rooms）; 
 var q3 = model.Buildings.Where（b => b.Id == buildingId）.First（）。 
 * / 
 
返回查看（查询）; 
} 
  

注释行只是其他方法，我可以得到我正在查看的查询结果对于。
Data.Model 是EF Db上下文。

我不喜欢这个是上下文是一次性的，而我并没有处理它。在我看来，这是懒惰和不好的做法。

我已经用模型测试了开始处理，第一次更改我需要的是返回查询的列表，我不介意，但是因为上下文被处理，在视图上我无法访问诸如 @ item.Building.Description 。所以如果处理我需要正确地返回我在视图上显示的内容（有多种方法可以做到这一点，所以我不太在意如何）。

另一个选择是在项目中的某处存在静态/共享上下文，因此所有数据库请求都使用相同的上下文实例。这是一个很好的一面，它只会使用一个DB连接，但EF可能已经在处理这个，所以我不想反对使用EF设计的方式，如果这应该是

所以，我的问题是，最好的做法是什么？

• 继续工作像我一样，实例化一个新的上下文，而不是处理。


• 每次处理上下文，并确保我在视图上返回任何需要显示的内容。


• 如果已经实例化，则使用一个返回静态上下文实例的类。

谢谢

解决方案

一般来说，我建议使用更加架构化的方法，并使用单独的（数据提供）层从数据库中获取数据。在这种情况下，IoC（控制反转）容器（如Ninject，Unity等）可以处理您的对象生命周期，但是如果您之前没有使用依赖注入模式，则需要先进行一些调查。 p>

尽管如此，简单的答案是您应该尽快处理您的上下文对象（一般来说，应尽可能短）。而通常的模式是

  using（var model = new Data.Model（））
 {
 var buildings = model.Rooms.Where（r => r.Building.Id == buildingId）.ToList（）; 
} 
  

您可以通过调用 ToList（ ）并处理上下文。这样可以避免在返回查询并将其传递给视图时遇到的问题。正如你所注意到的那样，控制什么时候你的数据库查询执行完毕，何时处理上下文，这真的很棘手。

另一个选项将是项目中某处的静态/共享上下文，因此所有数据库请求使用相同的上下文实例 - 这是一个可怕的想法和一个众所周知的坏实践/反模式。

总而言之，最佳做法是按照您在列表中的选项2中所描述的方式工作：每次处理上下文，并确保我返回任何需要在视图中显示的内容。

作为一个旁注，使用一个ViewModel per View（请参阅 ASP.NET MVC - 如何使用查看模型）

I apologise if my question seems dumb, I have tried Googling, and not found what I am looking for, so any advice would be appreciated.

I am fairly new to the Idea of MVC, I have been doing Web Forms development for a number of years, but I wanted to give something else a try.

I am using Entity Framework (6) for a database connection, and MVC4 for a web front end.

My question is, how should the DB context instance be handles.

My Controller Action code that is working is this

public ViewResult List(int buildingId)
{
    var model = new Data.Model();
    var query = from r in model.Rooms
                where r.Building.Id == buildingId
                select r;
    /*
    var q2 = model.Buildings.Where(b => b.Id == buildingId).SelectMany(b => b.Rooms);
    var q3 = model.Buildings.Where(b => b.Id == buildingId).First().Rooms;
    */

    return View(query);
}

The commented lines are just other ways I could get the query results I am looking for. Data.Model is the EF Db context.

What I don't like about this is that the context is disposable, and I am not disposing it. In my mind this is lazy and bad practice.

I have tested with model begin disposed, the first change that I require is to return a list of the query, which I don't mind, but then because the context is disposed, on the view I cannot access properties like @item.Building.Description. So if disposing I would need to return exactly what I was to display on the view (there are multiple ways I could do that, so I am not very worried about how).

Another option would be to have a static/shared context somewhere in the project, so all database requests use the same context instance. This is nice from the side that it would then only be using one DB connection, but EF might already be handling that for me, so I wouldn't want to go against using the way EF was designed, if this is how it should be.

So, my question is, what would be considered best practices?

• Keep working like I am, instantiating a new context, and not disposing.
• Dispose the context each time, and make sure I return anything I need visible on the view.
• Use a class that will return a static context instance if it is already instantiated.

Thank you

解决方案

Generally I would recommend to use a more architectured approach and use a separate (data-providing) layer for fetching data from the database. In that case an IoC (inversion on control) container (such as Ninject, Unity, etc.) could handle object lifetime for you, but if you haven't used Dependency Injection patterns before, you have a lot to investigate first.

Having said that, the simple answer is that you should definitely dispose your context objects as soon as possible (in general they should be as shortlived as possible). And the common pattern is

using (var model = new Data.Model())
{
    var buildings = model.Rooms.Where(r => r.Building.Id == buildingId).ToList();
}

You fetch the data right away by calling ToList() and dispose of the context. This avoids the problems you've encountered when returning a query and passing it to the view. As you've noticed, it gets really tricky to control when exactly your DB-query gets executed and when to dispose of the context.

Another option would be to have a static/shared context somewhere in the project, so all database requests use the same context instance - this is a horrible idea and a well-known bad practice/antipattern.

So to sum up, the best practice is working as you describe in Option 2 in your list: Dispose the context each time, and make sure I return anything I need visible on the view.

And as a sidenote, it is also a good practice to use a ViewModel per View (see ASP.NET MVC - How exactly to use View Models)

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