asp.net-mvc – 在MVC/ASP.NET MVC中正确使用Model vs Controller

前端之家收集整理的这篇文章主要介绍了asp.net-mvc – 在MVC/ASP.NET MVC中正确使用Model vs Controller前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我有一个名为GetProducts()的方法的Service类。这封装了业务逻辑,并调用存储库以获取产品列表。

我的MVC视图想要将产品列表显示为MVC SelectList。那个逻辑的正确位置在哪里。我似乎有3个选择:

>模型

该模型应该暴露一个名为ProductSelectList的属性。当该属性的getter由View调用时,Model应该调用Service.GetProducts()并将其转换为SelectList,然后再传递给它。

合理的论据:模型应该调用业务逻辑和存储库。视图应仅呈现预定数据。控制器不应该涉及,除了传递上下文数据到模型。
>查看

View应包含直接调用Service.GetProducts()的代码,并将结果转换为SelectList inline。

合理的参数:View应该直接调用此数据,因为它专门用于View。没有必要涉及模型或控制器,因为我们正在调用抽象的服务方法,所以其他任何东西只是增加额外的开销。
>控制器

Controller应该调用Service.GetProducts(),将结果转换为SelectList并将其传递给Model,该模型应该包含一个简单的ProductSelectList属性。 View将访问此属性进行渲染。

合理的参数:控制器知道要提供给服务方法的参数,因此它应该进行调用。该模型应该是数据的简单占位符,由控制器填充。 View的工作是简单地从Model中渲染数据。

我有一种感觉,正确的答案是模型,但其他两个做了一些合理的点。也许我已经弄脏了水域,已经有一个与模型分开的服务类?

有人会分享他们的意见吗?这只是味道的问题吗?

@R_301_323@

我个人订阅了第3号的逻辑,允许控制器填充模型(或有时有区别的查看模型)。

>我的看法很愚蠢,只显示数据。
>我有我的View Models存储视图需要的信息,偶尔会将格式化其他属性的“唯一”属性暴露为更好的格式。如果我的模型需要访问我的服务,那么我觉得我做错了。
>控制器将所有信息整合在一起(但不要为实际工作留下服务。

在你的例子中,我的控制器操作类似于:

public ActionResult Index()
{
    Indexviewmodel viewmodel = new Indexviewmodel();
    viewmodel.ProductSelectList = new SelectList(Service.GetProducts(),"Value","Name");
    return View(viewmodel);
}

和我的观点模型类似:

public class Indexviewmodel()
{
   public SelectList ProductSelectList { get; set; }
   public int ProductID { get; set; }
}

与适当的部分看法看起来像:

@Html.DropDownListFor(x => x.ProductID,Model.ProductSelectList);

这样我知道如果有任何问题,一切都有一个非常具体的地方,我知道在哪里看。

但是,没有正确的方法,似乎总是这样的事情。 Stephen Walther拥有a good blog series on MVC tips.在一个人中,他谈到了View Model的重点,虽然他并不是SelectList他所填充的,但SelectList仍然是数据,就像他的产品列表一样。

猜你在找的asp.Net相关文章