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

Question

我很好奇，如果绑定模型直接作为参数在行动方法被认为是坏主意？

如果表格变得复杂，我可以创建一个自定义模型联编程序。

有没有使用这种方法的任何坑？

我想避免创建viewmodel，因为我想让我的app尽可能简单。我想避免重复代码和模型视图到模型绑定。

Answer 1

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

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

使用ViewModel进行验证也更容易，因为您已经有了更加专注的模型，有时候验证只在某些视图中才有意义。

创建ViewModels比使用JsonResult发送模型好得多，也更安全...呃...即使您不使用ViewModel，也不应该发送域模型。但是当您准备好ViewModel时，使用JsonResult会更容易。当您习惯于在任何地方使用您的域模型时，犯错误和暴露敏感信息也更​​容易。

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

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

如果你想消除重复的代码，你可以考虑创建自动创建ViewModels的过滤器，甚至不用动作，使用映射器的过滤器消除了大量的代码重复。

顺便说一句，我看不出如何创建自定义模型绑定比使用ViewModels更简单。

Answer 2

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

也为一些属性，如DateTime，这将不能很好的示范，如果定义为DateTime因为不存在与使它可选的，所以你必须把它定义为string问题的工作。我不相信你想要约会string约会。

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

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

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映射视图模型< - >的DomainModel，即使在一个简单的场景。