0

我正在编写一个创建新用户的控制器操作。目前，控制器动作将用户实体模型作为参数。

我想知道我是否应该在自己的视图模型中从前端传递值，然后提取值并在后端创建实体？

public ActionResult AddUser(User user)
{
  context.Users.Add(user);
  context.SaveChanges();
}

对比

public ActionResult AddUser(UserViewModel userViewModel)
{
  var user = new User(userViewModel.Name);
  context.User.Add(user);
  context.SaveChanges();
}

谢谢！

4

2 回答 2

1

学术方法是创建一个额外的视图模型类，它只公开您需要显示的数据或用户需要输入信息的字段，并将它们映射到您的域模型，如您的第二个示例所示。

但是对于小型应用程序或当您需要模型中的所有字段时，我认为将域模型对象传递给视图是绝对可以的。

另一个需要考虑的重要事项是安全/验证。当使用隐式 mvc 映射机制和完整的域模型时，不良用户可能会将值发送到您不希望存储在数据库中的控制器。使用单独的视图模型类涉及显式映射步骤，您必须明确地告诉系统视图模型中的哪个字段（= 用户输入的数据）要映射到域模型。

于 2012-09-05T10:55:57.310 回答
1

与大多数事情一样，有多种方法可以做到这一点。最终在这种情况下，它通常归结为个人喜好。

当我做同样的事情时，我经常问自己传递给方法的内容是否真的有效User。我喜欢保持我的模型在内部防止无效状态，而不是依赖调用代码来保持模型的有效性。

因此，有时有些动作会接收描述模型的信息，但自身并不能完全构建模型。在这些情况下，我更喜欢使用视图模型。如果除了一致性之外没有其他原因，这通常会导致我全面使用视图模型。

如果我需要页面上多个模型的信息，它特别有用。拥有一个由我需要的信息组合而成的视图模型，而不是像Tuple两个模型中的一个，这对我来说感觉更干净。这也允许我向视图模型（计算字段、标志等）添加对视图有用但会污染业务对象的附加属性。（切换显示/隐藏某些表单元素、验证项等）

通常，通过注意对象( User) 和数据结构( )之间的区别，您可以找到自己对此类问题的偏好UserViewModel。在传统的面向对象意义上，User应该隐藏其数据成员并提供功能接口，而像平面数据结构一样UserViewModel会暴露其数据成员并且没有有意义的功能。

由于视图只是想绑定到数据成员，我通常使用平面视图模型而不是域对象。

于 2012-09-05T10:56:56.157 回答