ASP MVC 实体框架数据库上下文和类

Question

In my asp mvc Framework project, using EF, I have some objects (from classes) whose fields store data coming from my database.

My question is:

How to populate these fields, or manage methods of these objects using a dbcontext variable?

Sol 1: Is it better to use each time I need a connection with db in my classes with the instruction (using (resource), see below )?

Sol 2: Is it betterI to code a singleton class to use one instance of the context?

Sol 3: Or should I use another way for the links beetween my classes and the database?

What is the best method considering performances and code quality.

Thanks for your attention.

Solution 1

 public class Test
    {
        private  T1 a;
        private  T2 b;
       
        public Test()
        
        {}

        public void CreateFrom (int id) 
        
        {
            using (var db=new WebApplicationMVCTest.Models.dbCtx())
            {
                a=db.T1s.Find(id);
                b= db.T2s.Find(a.id2);
                
            }
        }

Solution 2:

public class DbSingleton
    {

        private static dbCtx instance;

        private int foo;

        private DbSingleton ()
            {}

        public static dbCtx Current
        {
            get
            {
                if (instance == null) 
                {
                    instance = new dbCtx();
                }
                return instance;
            }
        }


        public static void Set (dbCtx x)
        {

            if (instance==null)
            {
                instance = x;
            }
           

        }
 
    }

Answer 1

For a web project, never use a static DbContext. EF DbContexts are not thread safe so handling multiple requests will lead to exceptions.

A DbContext's lifespan should only be as long as it is needed. Outside of the first time setup cost when a DbContext is used for the first time, instantiating DbContexts is fast.

My advice is to start simple:

public ActionResult Create(/* details */)
{
    using (var context = new AppDbContext())
    {
         // do stuff.
    }
}

When you progress to a point where you learn about, and want to start implementing dependency injection applications then the DbContext can be injected into your controller / service constructors. Again, from the IoC container managing the DbContext, the lifetime scope of the Context should be set to PerWebRequest or equivalent.

private readonly AppDbContext _context;

public MyController(AppDbContext context)
{
    _context = context ?? throw new ArgumentNullException("context");
}

public ActionResult Create(/* details */)
{
    // do stuff with _context.
}

The gold standard for enabling unit testing would be injecting a Unit of Work pattern and considering something like the Repository pattern to make your dependencies easier to unit test.

The best advice I can give you starting out with EF and MVC is to avoid the temptation to pass Entities between the controller (server) and the UI. (views) You will come across dozens of examples doing just this, but it is a poor choice for performance, it also hides a LOT of land mines and booby traps for both performance, exceptions, and data security issues. The most important detail is that when the UI calls the controller passing what you expect will be an entity, you are not actually getting an entity, but a de-serialized JSON object cast to an entity. It is not an entity that is tracked by the DbContext handling the request. Instead, get accustomed to passing view models (serializable data containers with the data the view needs or can provide) and IDs + values where the controller will re-load entities to update the data only as needed.