模型本身应该进行一些计算吗？

Question

我已经学习ASP.NET MVC几个月了.我已经了解了视图和控制器以及模型和内容.要设计视图,我们总是需要一个模型.通常,模型只是一个我们用数据填充并传递给视图的类.我在这里有一个问题:一个模型本身应该做一些计算,还是应该只是愚蠢？

例如,我有一个网站,我Book用Users 加载s.我的模型类如下:

public class FormViewModel
{
  public User MyUser {get; set;}
  public Books UserBooks {get; set;}

  //Constructor here. 
  public FormViewModel(User _user, Books _userBooks)
  {
    this.MyUser=_user;
    this.UserBooks=_userBooks;
  }
}

这个类没有做任何事情 - 它只是一个模板.现在,如果我修改代码如下:

public class FormViewModel
{
  public User MyUser {get; set;}
  public Books UserBooks {get; set;}

  //Constructor here. 
  public FormViewModel(User _user)
  {
    this.MyUser=_user;
    this.UserBooks=_user.GetBooks();
  }
}

Book收集哪些s取决于哪个User被选中.现在,它更容易使用.

我只是想知道根据MVC模式和实践,什么是一个好方法.

Answer 1

您希望将所有业务逻辑和数据验证分离到模型中.通常包括"分组"数据集等,或按某些标准过滤数据.

您希望将所有对模型中这些方法的调用分开,控制器负责检索模型并从模型发送数据.然后,控制器将适用的数据集传递到视图中.

帮助程序是视图用于执行表示逻辑(而不是业务逻辑或验证)的逻辑,例如打印菜单等.

View是你将使用Helpers的地方(或者不是,他们不需要正确使用MVC,但他们"帮助":p)将HTML,CSS和JS写入浏览器.您还可以将常用的视图模块分成可包含在多个视图中的部分视图.

您可以进一步将事物分离到ViewModel中,但是您将超出"严格"MVC.在这种情况下,您将使用ViewModel来帮助视图与模型交互 - 基本上ViewModel是模块化控制器.在这种情况下,控制器会比它已经做的少得多.

但是,对于Web应用程序来说,这通常是过度的.因为Web应用程序具有单个执行流程(请求),所以将事物分离为ViewModel变得不必要.但是,在GUI代码中,ViewModel变得更加有用(因为GUI具有更多的单个执行流).

您总是希望将业务逻辑分成Model,period.请记住,您不应将控制器与模型耦合 - 这样您就可以在其他控制器的其他地方使用您的模型,甚至将其作为Web服务公开.

希望这可以帮助 :)