在 MVC 中将数据库上下文用于视图模型的位置

Question

控制器不应直接使用数据库上下文，存储库不应知道视图模型(表示)。

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

这个问题通常如何解决？

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

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

示例 2：存储库中的视图模型：

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

Answer 1

你真的不应该在你的控制器中有 DbContext。MVC 是一种表示模式。通常，访问数据存储(DBContext是)不是表示层的问题。

阅读有关 MVC Orchestrator 类的信息，正如 Dino Esposito 所解释的那样。

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

还可以使用在演示文稿模型和存储库模型之间实例化和映射的工厂类。例如，ProductFactory 知道如何在给定 ProductFromRepo 对象的情况下创建 ProductViewModel 对象(假设创建 ProductViewModel 对象所需的所有信息都可以从 ProductFromRepo 对象获得)，反之亦然。这些工厂类的唯一用途是将模型映射与业务流程协调程序和存储库分离。

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

Answer 2

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

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

因此，在通俗的术语中，视图模型表示需要按视图显示的数据。在这里，ViewModel没有任何其他责任，因此它是被动模型。

ViewModel 仅在 Web 端可用。它不应公开或与 BLL 或其他图层共享。