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中渲染数据。

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

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

解决方法

>我的看法很愚蠢，只显示数据。
>我有我的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仍然是数据，就像他的产品列表一样。

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!