什么时候应该创建一个新的 DbContext()

我目前使用的 DbContext类似如下:

namespace Models
{
public class ContextDB: DbContext
{
              

public DbSet<User> Users { get; set; }
public DbSet<UserRole> UserRoles { get; set; }


public ContextDB()
{
            

}
}
}

然后，我使用下面的行在 全部的顶部我的控制器，需要访问数据库。我也在我的 UserRepository 类中使用它，该类包含与用户相关的所有方法(比如获取活动用户，检查他拥有什么角色，等等):

ContextDB _db = new ContextDB();

考虑到这一点，有时一个访问者可以激活多个 DbContext，例如，如果它访问的控制器使用 UserRepository，这可能不是最好的想法。

什么时候应该创建一个新的 DbContext？或者，我是否应该有一个在所有地方传递和重用的全局上下文？这会影响性能吗？我们也欢迎提出替代方法的建议。

49767 次浏览
小开
最佳答案

I use a base controller that exposes a DataBase property that derived controllers can access.

public abstract class BaseController : Controller
{
public BaseController()
{
Database = new DatabaseContext();
}


protected DatabaseContext Database { get; set; }


protected override void Dispose(bool disposing)
{
Database.Dispose();
base.Dispose(disposing);
}
}

All of the controllers in my application derive from BaseController and are used like this:

public class UserController : BaseController
{
[HttpGet]
public ActionResult Index()
{
return View(Database.Users.OrderBy(p => p.Name).ToList());
}
}

Now to answer your questions:

When should I make a new DbContext / should I have one global context that I pass around?

The context should be created per request. Create the context, do what you need to do with it then get rid of it. With the base class solution I use you only have to worry about using the context.

Do not try and have a global context (this is not how web applications work).

Can I have one global Context that I reuse in all places?

No, if you keep a context around it will keep track of all the updates, additions, deletes etc and this will slow your application down and may even cause some pretty subtle bugs to appear in your application.

You should probably chose to either expose your repository or your Context to your controller but not both. Having two contexts being access from the same method is going to lead to bugs if they both have different ideas about the current state of the application.

Personally, I prefer to expose DbContext directly as most repository examples I have seen simply end up as thin wrappers around DbContext anyway.

Does this cause a performance hit?

The first time a DbContext is created is pretty expensive but once this has been done a lot of the information is cached so that subsequent instantiations are a lot quicker. you are more likely to see performance problems from keeping a context around than you are from instantiating one each time you need access to your database.

How is everyone else doing this?

It depends.

Some people prefer to use a dependency injection framework to pass a concrete instance of their context to their controller when it is created. Both options are fine. Mine is more suitable for a small scale application where you know the specific database being used isn't going to change.

some may argue that you can't know this and that is why the dependency injection method is better as it makes your application more resilient to change. My opinion on this is that it probably won't change (SQL server & Entity Framework are hardly obscure) and that my time is best spent writing the code that is specific to my application.

小开

Right now I am trying this approach, which avoids instantiating the context when you call actions that don't use it.

public abstract class BaseController : Controller
{
public BaseController() { }


private DatabaseContext _database;
protected DatabaseContext Database
{
get
{
if (_database == null)
_database = new DatabaseContext();
return _database;
}
}


protected override void Dispose(bool disposing)
{
if (_database != null)
_database.Dispose();
base.Dispose(disposing);
}
}
小开

This is obviously an older question but if your using DI you can do something like this and scope all your objects for the lifetime of the request

 public class UnitOfWorkAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(HttpActionContext actionContext)
{
var context = IoC.CurrentNestedContainer.GetInstance<DatabaseContext>();
context.BeginTransaction();
}


public override void OnActionExecuted(HttpActionExecutedContext actionContext)
{
var context = IoC.CurrentNestedContainer.GetInstance<DatabaseContext>();
context.CloseTransaction(actionContext.Exception);
}
}
小开

I try to answer out of my own experience.

1. When should I make a new DbContext / should I have one global context that I pass around?

The Context should be injected by the dependency-injection and should not be instantiated by yourself. Best-Practice is to have it created as a scoped service by the dependency-injection. (See my answer to Question 4)

Please also consider using a proper layered application structure like Controller > BusinessLogic > Repository. In this case it would not be the case that your controller receives the db-context but the repository instead. Getting injected / instantiating a db-context in a controller tells me that your application architecture mixes many responsibilities in one place, which - under any circumstances - I cannot recommend.

2. Can i have one global Context that I reuse in all places?

Yes you can have but the question should be "Should I have..." -> NO. The Context is meant to be used per request to change your repository and then its away again.

3. Does this cause a performance hit?

Yes it does because the DBContext is simply not made for being global. It stores all the data that has been entered or queried into it until it is destroyed. That means a global context will get larger and larger, operations on it will get slower and slower until you will get an out of memory exceptions or you die of age because it all slowed to a crawl.

You will also get exceptions and many errors when multiple threads access the same context at once.

4. How is everyone else doing this?

DBContext injected through dependency-injection by a factory; scoped:

services.AddDbContext<UserDbContext>(o => o.UseSqlServer(this.settings.DatabaseOptions.UserDBConnectionString));

I hope my answers where of help.

小开

You should dispose the context immediately after each Save() operation. Otherwise each subsequent Save will take longer. I had an project that created and saved complex database entities in a cycle. To my surprise, the operation became three times faster after I moved

using (var ctx = new MyContext()){...}

inside the cycle.

小开

In performance point of view, DbContext should be created just when it is actually needed, For example when you need to have list of users inside your business layer,you create an instance form your DbContext and immediately dispose it when your work is done

using (var context=new DbContext())
{
var users=context.Users.Where(x=>x.ClassId==4).ToList();
}

context instance will be disposed after leaving Using Block.

But what would happen if you do not dispose it immediately?
DbContext is a cache in the essence and the more you make query the more memory blocks will be occupied.
It will be much more noticeable in case of concurrent requests flooding towards your application, in this case,each millisecond that you are occupying a memory block would be of the essence, let alone a second.
the more you postpone disposing unnecessary objects the more your application is closed to crash!

Of course in some cases you need to preserve your DbContext instance and use it in another part of your code but in the same Request Context.

I refer you to the following link to get more info regarding managing DbContext:
dbcontext Scope


提交答案