为什么 laravel 模型中的功能点是？答案

【问题标题】：Why is the point of function in laravel models?为什么 laravel 模型中的功能点是？
【发布时间】：2018-04-16 22:15:01
【问题描述】：

为什么我需要在 laravel Model 文件夹中为文件定义函数。当从模块表中读取模块扩展模型值时，假设我现在有一个模型 Module.php。可以在控制器中使用函数，为什么还需要函数来操作数据库？

这里是 Module.php：

public function getStudentModules($id) {

    $student = Students::where('user_id', $id)->get();

    \DB::setFetchMode(\PDO::FETCH_ASSOC);

    $modules = \DB::table('course_modules')->
    where('course_id', '=', $student[0]->course_id)->
    select('module_id')->
    get();

    \DB::setFetchMode(\PDO::FETCH_CLASS);

    $results = Module::join('users', 'modules.lecturer_id', '=', 'users.id')->
    select('users.email', 'modules.id', 'modules.lecturer_id', 'modules.name', 'modules.code')->
    where('modules.semester', '=', $student[0]->semester)->
    whereIn('modules.id', $modules)->get();

    return $results;
}

这里是控制器：

public function lecturerViewExaminations($id)
  {
    $examinations =  /*Module::join('examination', 'modules.id', '=', 'examination.module_id')->
    select('modules.name as modulename', 'modules.code as modulecode', 'examination.name', 'examination.startdate', 'examination.enddate', 'examination.duration', 'examination.type', 'examination.code', 'examination.status', 'examination.id')->
    where('modules.lecturer_id', '=', $id)->get();*/

    return json_encode($examinations);
  }

当我可以在控制器中输入该函数时，为什么要在 Module.php 中定义？

【问题讨论】：

What exactly is the model in MVC 和 many, many others 的可能重复
没有不重复
因为模型应该包含业务逻辑并且应该“建模”您的数据。控制器是将模型与视图联系起来的胶水。 View 是您的应用程序的响应消息（输出）
如果你想要“原因”，我与许多优秀编程的原则、DRY（不要重复自己）、关注点分离、责任......等有关。
这是重复的，因为您显然不了解模型是什么以及它为什么存在。

标签： php laravel

【解决方案1】：

我感觉很好，所以我会告诉你我的想法。

很多都与 DRY 有关，不要重复自己。通常在 MVC 架构中，您不能真正从另一个控制器访问控制器。基本上你不加载或实例化控制器。架构就是这样做的。因此，通过将数据库代码放入控制器中，您可能无法从控制器外部轻松访问它。这将导致您必须在控制器的许多地方复制一些代码，如果您使用模型，您可以轻松访问和重用它。然后，当您进行架构更新时，您将不得不搜索所有臃肿的控制器方法并更改内容。

关注点分离，Controller 不应该关心数据的业务逻辑。例如，假设您有一个个人资料页面。现在控制器不应该关心用户模型如何与数据库交互。它已经不得不担心将数据提供给 User 模型、选择要使用的视图以及将任何输出分配给视图。为了让它负责与数据库的细粒度交互，控制器需要承担很多责任。所发生的不是几百行代码的方法，而是几千行代码。在这一点上，你不妨只是对它进行程序化编程。这再次使您的代码难以维护，因为很难判断给定控制器负责什么。而一个用户模型，它的职责应该是相当明显的。您不会期望用户模型处理产品或信用卡处理。责任太大了。你不会要求警察给你做手术。而且你不会要求外科医生逮捕你在酒吧被殴打的那个人。

黑盒，模型应该基本上是一个黑盒。控制器或视图不应该关心它们的内部工作。他们不应该关心使用什么数据库驱动程序（MySLQ、MSSQL、SqlLite 等）。也不，他们使用什么表，或者它是否使用文件或这些文件所在的路径等。他们不应该知道也不应该关心，因为他们有自己的工作要担心。控制器仅与模型提供的“接口”交互。通过这种方式，您可以替换模型的内部结构，只要它保持相同的接口，理想情况下您不需要对控制器进行任何代码更改。

我相信还有其他的，但这些是我能想到的与您的问题相关的大问题。

如果你开始把所有东西都混在一起，你最终会得到意大利面条式的代码。在快节奏的生产环境中，在实现所有这些想法的同时保持其井井有条是很困难的，相信我。

我实际上不是 MVC 的超级粉丝，它对我来说有点过于死板。不过，其中一些取决于 MVC 框架。我的意思是，其中很多都是基于一些强大的命名约定和位置要求。例如，所有控制器都必须位于名为 Controllers 的文件夹中，所有模型都必须位于名为 Models 的文件夹中。这使得制作独立的“插件”变得更加困难，因为您受到它们的命名约定或结构的限制。您最终会得到大量与框架紧密绑定的代码。

这是我的 2 美分。

PS。我实际上正在构建一个事件驱动的 MVC 框架:)

【讨论】：