Question

为什么我需要在文件的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中定义？

Answer 1

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

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

关注点分离，Controller不应该关注数据的业务逻辑。例如，假设您有个人资料页面。现在，控制器不应该关注用户模型如何与数据库交互。它必须担心将数据提供给用户模型，选择要使用的视图，并将任何输出分配给视图。为了使它与数据库的细粒度交互负责，在控制器的手中负担很多责任。所发生的是代替几百行代码的方法，你最终可以得到几千个代码。那时你可能只是程序化程序。同样，这使得维护代码变得困难，因为很难说出给定控制器的责任。而用户模型应该是相当明显的责任。您不希望用户模型处理说，产品或信用卡处理。这是太多的责任。你不会要求警察对你做手术。你不会要求外科医生逮捕你在酒吧被殴打的那个人。

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

我确信还有其他人，但这些是我能想到的与你的问题有关的重要事项。

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

我实际上并不是MVC的巨大粉丝，它往往有点过于僵化，不像我喜欢。其中一些依赖于MVC框架。我的意思是它们中的很多都基于一些强大的命名约定和位置要求而结束。例如，所有控制器必须位于名为Controllers的文件夹中，所有模型必须位于名为Models的文件夹中。它使得单独使用“插件”变得更加困难，因为它受到命名约定或结构的限制。你最终得到了很多与框架紧密相关的代码。

那是我的2美分。

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

为什么laravel模型的功能点？

1 个答案: