直接绑定域模型是一个坏主意吗？

Question

我很好奇将模型直接绑定为操作方法中的参数是否被认为是坏主意？

如果表单变得复杂，我可以创建一个自定义模型绑定器。

使用这种方法有什么陷阱吗？

我想避免创建视图模型，因为我想让我的应用程序尽可能简单。我想避免将代码和模型视图复制到模型绑定。

Answer 1

未必。但很快您就会发现模型上需要一些状态，但它是特定于 UI 的，无论如何您最终都会创建一个 ViewModel。

另外，对于某些属性（例如 DateTime），如果定义为 DateTime，则在模型上效果不佳，因为使其可选会出现问题，因此您必须将其定义为字符串。我不相信你想用 string 来表示日期。

此外，对于 DropDown 项目，您需要在模型上有一个用于 SelectListItem 的集合，这在模型上没有意义。

这就是发生在我身上的事。

Answer 2

我建议几乎总是使用视图模型。

如果您使用默认的对象模板...它们并不真正喜欢非平面模型，虽然您可以覆盖它们，但这并不总是一个好主意。领域模型通常不是平坦的。无论哪种方式，任何基于 ModelMetaData 的东西使用 ViewModel 都会变得更容易。

使用 ViewModel 进行验证也更容易，因为您有一个更有针对性的模型，有时验证仅在某些视图中有意义。

创建 ViewModel 比使用 JsonResult 发送模型更好、更安全......好吧......你永远不应该向外部发送域模型，即使你不使用 ViewModel。但是，当您准备好 ViewModel 时，使用 JsonResult 会更容易。当您习惯于在任何地方使用域模型时，也更容易犯错误并暴露敏感信息。

更改有时更容易，因为更改域模型上的属性并不意味着您必须更改所有视图，只需更改 ViewModel 的创建（如果您使用某种映射器，这只是对绑定的一个更改） ），尽管在我看来这不是一个非常强的点。

其他一些好处是将表示层与业务层解耦，如果您使用 EF 或非 poco 对象，则在视图中使用它们会更困难。

如果您想消除代码重复，您可以考虑创建自动创建 ViewModel 的过滤器，即使没有操作过滤器，使用映射器也可以消除大量代码重复。

顺便说一句，我不明白创建自定义模型绑定器比使用 ViewModel 更简单。

Answer 3

我建议您始终创建一个 ViewModel。在最简单的形式中，它可能只包含具有域对象（和附件数据）的属性。比如：

public class DomainModelClass
{
    int Property1 { get; set; }
    int Property2 { get; set; }
}

public class ViewModelClass
{
    DomainModelClass DomainModel { get; set;}

    SelecList List1 { get; set; }
}

无论如何，这个建议只是为了让事情变得简单，因为我建议你创建一个“真正的”视图模型，并使用像 AutoMapper 这样的东西来映射 ViewModel <-> DomainModel，即使在简单的场景中也是如此。