真的是快速提问。
我目前正在使用 asp.net MVC 和实体框架构建一个站点。我有几个存储库可以返回实体或实体列表。我发现在我的大部分页面中,我不得不从各种相关表中提取数据。只要我在查询中使用“包含”加载相关实体就可以了——但这是一种好的做法吗?
创建一个只包含我需要的信息位的自定义视图模型对象会更好吗,或者拉一个可能有 5 到 6 个表深的对象图只是为了在视图中显示你需要的东西,这没有什么“错误”吗?
抱歉,如果这个问题没有太大意义。我可能从根本上误解了应该如何在这里使用模型:)
谢谢
真的是快速提问。
我目前正在使用 asp.net MVC 和实体框架构建一个站点。我有几个存储库可以返回实体或实体列表。我发现在我的大部分页面中,我不得不从各种相关表中提取数据。只要我在查询中使用“包含”加载相关实体就可以了——但这是一种好的做法吗?
创建一个只包含我需要的信息位的自定义视图模型对象会更好吗,或者拉一个可能有 5 到 6 个表深的对象图只是为了在视图中显示你需要的东西,这没有什么“错误”吗?
抱歉,如果这个问题没有太大意义。我可能从根本上误解了应该如何在这里使用模型:)
谢谢
如果你的观点开始做类似的事情
<% foreach (var order in Model.Orders.Any(x => x.Products.Any(p => p.Category == "xx")) %>
那么你肯定需要 ViewModel。你可以和
ViewData["flattened_orders"]
如果您更喜欢魔术弦,但我对此表示怀疑。
然后,您的实体需要演示属性的问题,然后您需要公开它们的所有属性,以便模型绑定器可以工作......然后您需要额外的仅演示信息,如国家列表......
因此,对于简单的应用程序,您可以跳过 ViewModel。但是对于简单的应用程序,无论如何您都可以执行 Response.Write 和手动 SQL ;-)
我其实很喜欢这篇关于类似问题的帖子。那里所代表的方法一开始可能看起来太“学术”了,但它来自真实的项目,我做的 ASP.NET MVC 越多,我就越喜欢它,也越来越接近它。
我建议您查看视图中的渲染代码和控制器中的发布代码。您采用的方法是否使它们过于复杂?如果不是,您可能可以保持原样。如果通过引入自定义视图模型可以大大简化视图和控制器代码,那么请考虑创建一个。自定义视图模型本质上抽象了一些目前可能正在其他地方处理的复杂性。