在使用MVC时,我发现我的视图在其关联的模型定义方面是僵化的。我应该根据观点的需要设计我的模型吗?我意识到我可以专门为我的视图创建一个容器。然后根据实体设计第二个模型。但是,似乎我总是需要这种立场。我的意思是,甚至有一个@model
来声明View应该耦合到什么。
例如,我有一个包含两个表的视图。这些表都在同一个实体上运行,因此将该实体用作模型是没有意义的。相反,Model需要是一个包含2个所述实体的包装器。此外,实体确实需要转换为string[]
,以避免在视图中进行数据按摩。
我是不是一个MVC nublet,或者这是MVC的设计工作方式?与View-Model的紧密关系。
答案 0 :(得分:1)
通常情况下,我认为很多SO / MVC社区都同意遵循View Model-esque模式即使在您描述的情况下也是非常有益的。将您的实体包装在视图模型类中,并将其绑定在视图开头的@model
语句中。
微软的人推荐了相同的内容,但这不是绝对的法律。
有时看起来非常繁琐,但除非您编写自己的视图引擎并结合一些超级高级模型绑定逻辑,否则更容易路径通常被视为视图模型。使用数据注释添加更多乏味以进行验证等。但说实话,如果需要高级模型绑定和自定义视图引擎,您的问题可能已经过多考虑。
我同意,不要将实体类直接传递给模型。使用视图模型调用服务或BL类,它们从数据存储中组装数据实体。每个视图模型使用1个视图时,我发现了最大的灵活性。 重申一下,视图模型类和视图之间的比例为1:1 。即使必须将视图分解为可管理的部分,也可以使用显示和编辑器模板来完成您的需要。它会帮助你以后:)
答案 1 :(得分:1)
使用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; }
}