Question

在使用MVC时，我发现我的视图在其关联的模型定义方面是僵化的。我应该根据观点的需要设计我的模型吗？我意识到我可以专门为我的视图创建一个容器。然后根据实体设计第二个模型。但是，似乎我总是需要这种立场。我的意思是，甚至有一个@model来声明View应该耦合到什么。

例如，我有一个包含两个表的视图。这些表都在同一个实体上运行，因此将该实体用作模型是没有意义的。相反，Model需要是一个包含2个所述实体的包装器。此外，实体确实需要转换为string[]，以避免在视图中进行数据按摩。

我是不是一个MVC nublet，或者这是MVC的设计工作方式？与View-Model的紧密关系。

Answer 1

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

微软的人推荐了相同的内容，但这不是绝对的法律。

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

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

Answer 2

使用ViewModel查看您的观看次数。将View与直接来自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 Best Practices
ASP.NET MVC View Model Patterns

MVC3 - 我应该将我的模型设计为与我的视图紧密耦合吗？

2 个答案: