我应该把我的模型设计成与视图紧密耦合吗?

Question

在使用MVC时，我发现我的视图在其相关的模型定义方面是严格的。我应该围绕视图的需要来设计模型吗?我意识到我可以专门为我的视图创建一个容器。然后根据实体设计第二个模型。但是，我似乎总是需要这个中间人。我的意思是，甚至有一个@model来声明视图应该耦合到什么。

例如，我有一个包含两个表的视图。这两个表都在同一个实体上工作，所以使用实体作为模型是没有意义的。更确切地说，模型需要是一个包含上述实体中的2个的包装器。此外，实体确实需要转换为string[]，以避免视图中的数据传递。

我只是太多的MVC小块，或者这是MVC是如何设计工作的?与视图模型的紧密关系。

Answer 1

为视图使用ViewModel。将视图与直接来自EF的模型关联起来是不好的做法。

public class ProductViewModel
{
    public ProductViewModel(List<Product> products, List<Category> categories)
    {
        this.Products = products;
        this.Categories = categories;
    }
    public List<Product> Products { get; private set; }
    public List<Category> Categories { get; private set; }
}

ViewModel最佳实践
ASP。. NET MVC视图模型模式

Answer 2

通常，我认为很多SO/MVC社区都会同意，即使在您描述的情况下，遵循视图模型式模式也是非常有益的。将实体包装在视图模型类中，并在视图开头的@model语句中将其绑定。

微软的人也推荐了同样的做法，尽管这不是绝对的法律。

有时看起来非常乏味，但除非您编写自己的视图引擎并结合一些超级高级的模型绑定逻辑，否则更容易的路径通常是视图模型。为验证添加更多的数据注释，等等。但老实说，如果需要高级模型绑定和自定义视图引擎，你的问题可能已经考虑得太多了。

我同意，不要把实体类直接传递给模型。使用视图模型来调用服务或BL类，它们从数据存储中组装数据实体。我发现使用每个视图一个视图模型时最灵活。重申一下，视图模型类和视图之间的比例是1:1。即使必须将视图分解为可管理的部分，也可以使用显示和编辑器模板来完成所需的工作。它以后会帮到你的:)