Question

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

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

有没有使用这种方法的pitfals？

我想避免创建viewmodel，因为我想让app尽可能简单。我想避免将代码和modelview复制到模型绑定。

Answer 1

不一定。但很快您会发现某些状态需要在模型上，但是特定于UI，最后您最终会创建一个ViewModel。

对于某些属性，例如DateTime，如果定义为DateTime，这在模型上将无法正常工作，因为将其设置为可选，因此您必须将其定义为{{1} }}。我不相信你想让string约会。

此外，对于DropDown项目，您需要在模型上为string设置一个对模型没有意义的集合。

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

Answer 2

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

如果您使用的是默认对象模板......他们并不喜欢非平面模型，虽然您可以覆盖它们，但它并不总是一个好主意。域模型通常不平坦。无论哪种方式，使用ViewModel都可以更轻松地使用ModelMetaData。

使用ViewModel验证也更容易，因为您有一个更集中的模型，有时验证只在某些视图中有意义。

创建ViewModel比使用JsonResult发送模型更好更安全......嗯......即使你没有使用ViewModels，你也不应该在外面发送域模型。但是当你准备好ViewModel时，使用JsonResult会更容易。当您习惯在任何地方使用域模型时，也会更容易出错并暴露敏感信息。

更改有时更容易，因为更改域模型上的属性并不意味着您必须更改所有视图，只需更改ViewModel的创建（如果您使用某种映射器，那只是一个更改虽然这不是一个非常强大的IMO点。

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

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

是的，我不知道创建自定义模型绑定器比使用ViewModels更简单。

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＆lt; - ＆gt; DomainModel，即使在一个简单的场景中。

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

3 个答案: