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

【问题标题】：ASP MVC Entity Framework Database context and classesASP MVC 实体框架数据库上下文和类
【发布时间】：2021-05-19 19:52:02
【问题描述】：

在我的 asp mvc 框架项目中，使用 EF，我有一些对象（来自类），其字段存储来自我的数据库的数据。

我的问题是：

如何填充这些字段，或使用 dbcontext 变量管理这些对象的方法？

解决方案 1：每次我需要在我的课程中使用指令与 db 建立连接时使用会更好吗（使用（资源），见下文）？

解决方案 2：编写一个单例类以使用上下文的一个实例更好吗？

Sol 3：或者我应该为我的课程和数据库之间的链接使用其他方式吗？

考虑性能和代码质量的最佳方法是什么。

感谢您的关注。

解决方案 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);
                
            }
        }

解决方案 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;
            }
           

        }
 
    }

【问题讨论】：

标签： c# entity-framework class model-view-controller

【解决方案1】：

对于网络项目，从不使用静态 DbContext。 EF DbContexts 不是线程安全的，因此处理多个请求会导致异常。

一个 DbContext 的生命周期应该只在需要的时候。除了第一次使用 DbContext 时的首次设置成本之外，实例化 DbContext 速度很快。

我的建议是从简单开始：

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

当您了解并想要开始实现依赖注入应用程序时，可以将 DbContext 注入到您的控制器/服务构造函数中。同样，从管理 DbContext 的 IoC 容器中，应将 Context 的生命周期范围设置为 PerWebRequest 或等效项。

private readonly AppDbContext _context;

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

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

启用单元测试的黄金标准是注入一个工作单元模式并考虑像存储库模式这样的东西，以使您的依赖项更容易进行单元测试。

从 EF 和 MVC 开始，我可以给您的最佳建议是避免在控制器（服务器）和 UI 之间传递实体的诱惑。 (views) 你会遇到几十个这样做的例子，但它在性能方面是一个糟糕的选择，它还隐藏了很多性能、异常和数据安全问题的地雷和陷阱。最重要的细节是，当 UI 调用控制器传递您期望的实体时，您不是实际上获得的是实体，而是反序列化的 JSON 对象投射到一个实体。它不是由处理请求的 DbContext 跟踪的实体。相反，要习惯于传递视图模型（具有视图需要或可以提供的数据的可序列化数据容器）和 ID + 值，控制器将在其中重新加载实体以仅在需要时更新数据。

【讨论】：