asp.net-mvc - ASP.NET MVC - 究竟如何使用 View 模型

Question

假设我有一个允许编辑用户详细信息的页面，因此我有一个如下所示的 ViewModel:

public class UserViewModel {
    public string Username { get; set; }
    public string Password { get; set; }
    public int ManagerId { get; set; }
    public string Category { get; set; }
}

因此，在我的 EditUser 操作中，我可以将其由模型绑定(bind)器传回，然后我可以将其映射到域模型:

public ActionResult EditUser(UserViewModel user) {
    ...

但是，显示表单的页面还需要经理和类别列表等详细信息，以便为这些字段提供下拉列表。它还可能会在侧边栏中显示其他用户的列表，以便您可以在正在编辑的不同用户之间进行切换。

那么我就有了另一个 View 模型:

public class ViewUserViewModel {
    public UserViewModel EditingUser { get; set; }
    public IEnumerable<SelectListItem> Managers { get; set; }
    public IEnumerable<SelectListItem> Categories { get; set; }
    public IEnumerable<SelectListItem> AllUsers { get; set; }
}

这是正确的方法吗？它们都是 View 模型吗？如果是这样，我是否应该使用命名约定，以便可以区分类似模型的虚拟机和仅包含页面数据的虚拟机？

我是不是搞错了？

Answer 1

“ View 模型”只是一种模式。这个名称并没有什么神奇之处，但通常任何传递给 View 的类(无论是为了简单地显示数据还是为了表单提交)都被称为“ View 模型”，并被赋予像 FooViewModel 这样的名称。 code> 或 FooVM 来指示它是“ View 模型”模式的一部分。

我不想对你说得太哲学化，但我认为一些关于游戏模式的引用会有所帮助。 ASP.NET MVC 显然足够鼓励 MVC(模型- View - Controller )架构模型。在 MVC 中，模型是所有应用程序业务逻辑的容器。 Controller 负责处理请求、获取模型、使用该模型渲染 View 并返回响应。这看起来责任很大，但实际上框架在幕后处理了大部分工作，因此 Controller 通常(并且应该)只需要很少的代码。他们负责连接所有东西的最低限度的功能。最后， View 负责创建 UI 层，允许用户与模型中的数据进行交互。它对数据本身不负责，也不应该负责(ViewData/ViewBag 在这里是一个相当大的违规，至少在开发人员最终在实践中使用它的方式上是如此)。

因此，这意味着您的大部分应用程序逻辑应该位于您的模型中，通常这是一件好事。但是，由于模型是应用程序数据的避风港，因此它通常会保存在数据库或类似数据库中。这会产生一些利益冲突，因为您现在需要在应该保留哪些数据和应该仅出于显示目的而存在的数据之间开始平衡。

这就是 View 模型的用武之地。MVVM(模型- View - View 模型)是一种与 MVC 有点并行的模式，它认识到单一模型统治所有方法的固有问题。我不会在这里详细介绍，因为 MVC 不使用这种模式。然而，大多数 ASP.NET MVC 开发人员都选择了 MVVM 的 View 模型。您最终得到的实际上是一个数据库支持的实体(传统模型)，然后通常是许多不同的 View 模型，这些 View 模型代表处于不同状态的实体。这允许您的模型包含与持久性相关的业务逻辑，而 View 模型包含与显示、创建和更新该模型相关的业务逻辑。

我有点偏离了轨道，但总而言之，你所做的事情是完全可以接受的。事实上，这是一个很好的做法。根据应用程序的需要创建尽可能多的 View 模型，并使用它们来实际存储 View 所需的数据和业务逻辑。 (其中包括诸如 SelectList 之类的内容。您的 Controller 和 View 都不需要知道如何为下拉列表创建 SelectList。)