MVC 中视图模型在哪里使用 db 上下文

Question

控制器不应该直接使用数据库上下文，并且存储库不应该知道视图模型（表示）。

根本问题当然是避免从数据库中选择所有列，只选择那些需要的列。

这个问题一般是怎么解决的？

示例 1：控制器中的数据库上下文：

public ActionResult Products()
{         
   var model = from p in _context.Products 
   select new ProductItemViewModel
   {
           ProductName = p.ProductName
   };
   return View(model);        
}

示例 2：存储库中的 ViewModel：

public ProductItemViewModel Products()
{         
  return  from p in _context.Products 
    select new ProductItemViewModel
    {
       ProductName = p.ProductName
    };
}

Answer 1

您的控制器中确实不应该有 DbContext。 MVC 是一种表示模式。通常，访问数据存储（DBContext 是）不是表示层关心的问题。

阅读一下MVC Orchestrator classes, as explained by Dino Esposito。

Orchestrator 类有点像 MVC 应用程序的服务层。 Orchestrator知道（但不一定理解）您在 MVC 中的表示模型（“M”），以及您的存储库中的模型接受或返回。 Dino 的 Orchestrator 类的主要目的实际上是从 Controller 类中删除应用程序逻辑，并使它们易于测试和重用。您的控制器仅负责与 Web 相关的流程（例如，确保请求经过身份验证，或从 HTTP 上下文中获取信息，或重定向请求或编写 HTTP 响应）。

您还可以使用 Factory 类来实例化和映射您的表示模型和存储库模型。例如，ProductFactory 知道如何在给定 ProductFromRepo 对象的情况下创建 ProductViewModel 对象（假设创建 ProductViewModel 对象所需的所有信息都可以从 ProductFromRepo 对象中获得），和/或反之亦然。这些工厂类的唯一目的是将您的模型映射与您的 Orchestrator 和您的存储库分离。

更新： 要回答您的评论，您的存储库的设计取决于您。人们通常认为它应该返回数据库模型。但是您的存储库可能会返回 DTO 甚至域模型。这实际上取决于您如何设计存储库和应用程序架构。

Answer 2

根据我的知识和想法，您必须阅读更多有关 MVC 的内容。这就是我的想法。

MVC 中的 (M) 是表示数据的模型，但它表示来自数据库或其他可以在视图端表示的外部资源端的数据。现在的问题是需要显示数据的视图有时需要显示来自多个模型的数据，因此 ViewModel 出现了。

所以通俗的说 ViewModel 代表的是需要通过视图展示的数据。这里 ViewModel 没有任何其他责任，所以它是被动模型。

ViewModel 仅在 Web 端可用。它不应暴露或与 BLL 或其他层共享。