Question

在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。将两个模型组合成一个模型并为每个控制器设置专用模型是否更好？

Answer 1

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

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

Answer 2

实际上，这些场景有标准方式。
的 Unit Of Work & Generic Repository with Entity Framework 5

另外，请访问此帖： Understanding and Implementing Repository and Unit of Work Pattern in ASP.NET MVC Application

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


现在想象一下我们在中有多个表的场景   数据库。然后我们需要创建多个存储库才能映射   域模型到数据模型。现在拥有多个存储库   课程对问题产生了影响。

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

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

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

2 个答案: