在 MVC 中使用 DBCONTEXT 类的正确方法

本文关键字：方法 DBCONTEXT MVC | 更新日期: 2023-09-27 18:30:20

在MVC中，我们创建了Dbcontext模型，例如

 public class Model1 : DbContext
    {
        public Model1()
            : base("DefaultConnection")
        {}
        public DbSet<SomeObj> SomeObjSet { get; set; }
    }
//another model
 public class Model2 : DbContext
        {
            public Model2()
                : base("DefaultConnection")
            {}
            public DbSet<SomeObj2> SomeObjSet { get; set; }
        }

然后我们使用像这样的控制器

public class SomeController : Controller
    {
        private Model1 db1 = new Model1();
        private Model2 db2 = new Model2();
        public ActionResult Action1()
        {
            //do sth with Model1 and return
            return View(db1.SomeObjSet.ToList());// 
        }
         public ActionResult Action2()
        {
            //do sth with Model2 and return result
            return View(db2.SomeObjSet.ToList());// 
        }

但我的问题是，通过这种方式我们正在创建 多重DBConnections .将两个模型合并为一个模型并为每个控制器提供一个专用模型是否更好？

在 MVC 中使用 DBCONTEXT 类的正确方法

但我的问题是，并不是说我们以这种方式创建了多个DBConnections。

不，不用担心。实体框架（或更具体地说，它所依赖的 ADO.NET 实体框架）处理连接池中的实际数据库连接。因此，不要将 DbContext 与实际的 DbConnection 混淆。这是两件完全不同的事情。

实际上，这些类型的场景有标准方法。
具有实体框架 5 的工作单元和通用存储库

另外，请访问这篇文章： 了解和实现 MVC 应用程序中 ASP.NET 存储库和工作单元模式

我正在从第二个链接复制下面的一些文本。

现在想象一下我们在 数据库。然后我们需要创建多个存储库以映射 域模型到数据模型。现在有多个存储库 类提出问题。

问题在于 ObjectContext 对象。如果我们创造 多个存储库，如果它们包含其 ObjectContext 分别？我们知道使用多个 ObjectContext 实例 同时对象可能是一个问题，所以我们真的应该允许每个 存储库是否包含自己的实例？

来解决这个问题。为什么让每个存储库类实例具有 它自己的 ObjectContext 实例。为什么不创建 ObjectContext 位于某个中心位置，然后将此实例传递给 存储库类，只要它们正在实例化。现在这个 新类将称为工作单元，该类将 负责创建 ObjectContext nstance 并移交 控制器的所有存储库实例。

相关文章：