MVC处理数据库操作模型vs控制器类

问题描述：

我正在创建我的第一个MVC项目，尽管不是编程新手。据微软：MVC处理数据库操作模型vs控制器类

一个MVC模型包含不包含在一个视图或控制器的所有应用程序逻辑的。该模型应该包含您的所有应用程序业务逻辑，验证逻辑和数据库访问逻辑。例如，如果您使用Microsoft Entity Framework来访问数据库，那么您将在Models文件夹中创建实体框架类（您的.edmx文件）。视图应该只包含与生成用户界面相关的逻辑。控制器应该只包含返回正确视图或将用户重定向到另一个操作（流量控制）所需的最少逻辑。其他一切都应该包含在模型中。一般来说，你应该争取胖的模型和瘦的控制器。你的控制器方法应该只包含几行代码。如果控制器操作太胖，那么您应该考虑将逻辑移出到Models文件夹中的新类。

起初我写的所有数据库逻辑控制器类。我已经成功地在模型类中重写了它的大部分内容，但是这种方法存在一些主要问题，我希望得到澄清。

，首先是所有的UrlHelper/HttpRequestBase /的HttpContext/ModelStateDictionary，所有这些功能都是您控制器类的一部分。它被写成好像你应该在控制器类中完成大部分的处理。

例如我的控制器类，一旦你注册一个新的账号：

而且我的模型类：

public bool register(RegisterViewModel model, UrlHelper url, HttpRequestBase request, ModelStateDictionary modelState) 
    { 
     if (userManager.FindByEmail(model.Email) != null) 
     { 
      modelState.AddModelError("Email", "Error, already have this email registered!"); 
      return false; 
     } 
     else 
     { 
      MyIdentityUser user = new MyIdentityUser(); 

      user.Email = model.Email; 
      user.FullName = model.FullName; 
      user.UserName = model.Email; 

      IdentityResult result = userManager.Create(user, model.Password); 

      if (result.Succeeded) 
      { 
       userManager.AddToRole(user.Id, "ReadOnly"); 

       string code = userManager.GenerateEmailConfirmationToken(user.Id); 
       var callbackUrl = url.Action("ConfirmEmail", "Account", new { userId = user.Id, code = code }, protocol: request.Url.Scheme); 
       userManager.SendEmail(user.Id, "Confirm your account", "Please confirm your account by clicking" + System.Environment.NewLine + "<a style=\"border:15px solid #00FF00;background-color:#00FF00;color:#000;font-size:14px; font-family:Arial;text-decoration:none\" href =\"" + callbackUrl + "\">here</a>"); 

       return true; 
      } 
      else 
      { 
       modelState.AddModelError("Email", "Error while creating the user!"); 
       return false; 
      } 
     } 
    }

在这个模型类，我到ModelState中，UrlHelper进不去， HttpRequestBase，因为它们都是控制器类的一部分。

我是否应该将所有这些变量传入我的模型类以访问它们？看起来像微软写这个来做控制器中的所有逻辑，即使他们不这样做。只是不明白为什么不在控制器中这样做，不必将所有这些变量传递给模型类。

哦，没有。我喜欢将它概念化的方式是我们有用于与数据库进行通信的实体模型（通过实体框架）。这些是POCO类。控制器出去拿取我们的实体，我们填充ViewModel以满足我们的特定需求（例如添加发票）。然后我们用ViewModel调用我们的视图，当表单发回时我们验证并保存。看到这个https://lostechies.com/jimmybogard/2009/04/24/how-we-do-mvc/ –

答

在您给出的引用中，“模型”是指实体框架模型，即域逻辑。

甲查看模型应与显示逻辑，例如有关在显示它之前预处理从后端检索的一些数据。将Register方法放在正确的地方是控制器或Controller调用的某些应用程序/域服务。

从创建Visual Studio中的模板创建一个新的MVC项目，并有一个看看的AccountController看到MS如何实现用户注册。

答

MVC与微软无关 - 这是一个20年前的概念。认真。

是的，模型是 - 模型。很少有逻辑发生在他们（大多数：无），当我看到你的看法，我看到太多的代码。这不是一个模型。

你必须模型中的所有这些变量不能访问的原因是，你不需要他们。你不应该做任何不涉及在模型中呈现数据的处理。你做什么。

所以我应该在实际的控制器POST类中做这个逻辑？即使我创建一个服务类，它也会和这个模型类相似，因为它不会成为控制器的一部分，并且不能访问这些变量。这就是我要做的...... 你的控制器方法应该只包含几行代码。如果控制器操作太胖，那么您应该考虑将逻辑移出到Models文件夹中的新类。 – user1779362

取决于你多久做一次 - 没有人说控制器必须自己完成所有的工作。你也可以让一个模型有子模型，并通过子视图呈现（用于重复元素）或在这里使用继承。只要用尽可能少的逻辑来保持模型“愚蠢”。 – TomTom

答

该视图用于“查看”结果...它告诉要从“控制器”显示什么，并且控制器获取有关如何从模型构建数据的信息...

是这样的...

首先，我们需要在模型中定义的表...

public partial class MyTable 
{ 
    public int ID { get; set; } 
    public string Name { get; set; } 
    public string Description { get; set; } 
}

让您的数据，请在控制器中的任何修改......

public class MyController : Controller 
{ 
    MyEntities db = new MyEntities();   //Set the context for your DB 
    var dataToPassToView = db.MyTable.ToList(); //Get your data from the DB 

    //Make any changes/calculations to your data before passing it to the view... 

    return View(dataToPassToView);    //Return the View along with your data 
}

和视图...

@model IEnumerable<MyApp.Models.MyTable> //Tell the view what model to use 
///Some Code in here to display your data...

正如你可以看到，该模型是唯一定义的数据结构。控制器在显示数据之前“控制”数据......视图从控制器获取完成的产品，并根据指示显示它。

MVC处理数据库操作模型vs控制器类

相关推荐