关于最佳实践的简单问题。说我有:
public class Product
{
public string Name { get; set; }
public string Price { get; set; }
public int CategoryID { get; set; }
public bool IsAvailable { get; set; }
}
我有一个使用IEnumerable<的视图产品与GT;作为模型,我遍历页面上的产品,并希望显示列表末尾的总价格,我应该使用:
<%= Model.Sum(x=> x.Price) %>
还是应该使用其他方法?这可能扩展到包括更多涉及的内容:
<%= Model.Where(x=> x.CategoryID == 5 && x.IsAvailable).Sum(x=> x.Price) %>
甚至
<% foreach (Product p in Model.Where(x=> x.IsAvailable) {%>
-- insert html --
<% } %>
<% foreach (Product p in Model.Where(x=> !x.IsAvailable) {%>
-- insert html --
<% } %>
我想这归结为我应该在我的视图中有那种代码,还是应该将它传递给我在ViewData中的视图?或者其他一些方式?
答案 0 :(得分:2)
如果您在页面上使用的逻辑与页面上的数据显示有关,那么使用进行计算的逻辑我没有问题。计算控制器中的值并将其作为模型的一部分提供将显示器耦合到控制器执行的操作,即,如果您只是想更改数据的显示方式 - 例如,按类别分组和显示子-totals - 并且期望模型中的所有数据,然后您必须触摸控制器和视图才能进行更改。如果将与显示相关的计算放在视图中,则只需要更改视图。
关于逻辑是与业务相关还是与视图相关的调用依赖于上下文。例如,您可能有一个业务规则,表明您只显示可用的产品。执行此规则当然不应该是视图的功能,因此,在这种情况下,您应该将其移动到控制器(甚至模型)中。但如果它是一个简单的购物车内容计算或根据模型属性过滤你显示的东西,我会在视图中使用它。
答案 1 :(得分:0)
我会把这个逻辑推回到控制器和“视图模型”中。我认为这是“视图模型”。一个简单的例子是
return View(new ProductSummaryViewModel
{
Products = products,
TotalPrice = products.Sum(p => p.Price)
});
显然,无论视图必须显示什么,您都可以扩展它。您甚至可以拥有子视图模型的集合,这些集合可以使事情变得更加容易。
希望这有帮助