修改 Mojolicious 中的默认控制器/模型路径答案

【问题标题】：Modify default Controller/Model paths in Mojolicious修改 Mojolicious 中的默认控制器/模型路径
【发布时间】：2021-10-25 00:58:48
【问题描述】：

我希望能够从默认的 Mojolicious 路径中移动控制器、模型等：

  - App
    - Controller
      - Namespace1
        - ...
      - Namespace2
        - ...
    - Model
      - Namespace1
        - ...
      - Namespace2
        - ...

变成更易于管理的东西，例如：

  - App
    - Namespace1
      - Controller
        - ...
      - Model
        - ...
    - Namespace2
      - Controller
        - ...
      - Model
        - ...

所以不是

$r->any('/api/test')->to('Namespace1::Controller1#test');

我可以这样称呼

$r->any('/api/test')->to('App::Namespace1::Controller1#test');

如何在 Mojolicious 中实现这一点？

【问题讨论】：

最后一个代码示例不应该是App::Namespace1::Controller::Controller1吗？无论如何，您能否详细说明您正在尝试做什么，您尝试过什么以及什么不起作用？例如，执行->to('Namespace1::Controller1#...') 应该可以工作，而无需修改任何设置或做任何花哨的事情。对于渲染模板，您可能希望在某处更新 $self->app->renderer->paths，但您似乎并不关心问题中的模板。

标签： perl model-view-controller mojolicious

【解决方案1】：

原来你可以这样指定命名空间：

    $r->any('/api/test')->to(
        namespace => 'App::Namespace1',
        controller => 'Controller::Controller1',
        action => 'test'
    );

这会从控制器App::Namespace1::Controller::Controller1调用test方法

详情请见Mojolicious Routing

【讨论】：

【解决方案2】：

我不知道你在做什么，但看起来你的 Mojo 应用程序中可能有太多模式代码。也许不是，但我见过这种模式几次。如果这不适用于您，请忽略它。它当然适用于可能阅读您问题答案的其他人。

首先，我已经完成了您所做的：在to() 中指定前缀命名空间。我更喜欢这样，因为它可以帮助我（和其他人）在有很多控制器命名空间（以及消除冲突命名空间冲突）的项目中找到类。

您还可以推送命名空间前缀：

push @{$app->routes->namespaces}, 'MyApp::MyController';

人们倾向于将几个不同的服务塞进一个单一的 Mojo 应用程序中，这最终会导致某种冲突。例如，考虑两组完全不同的路由，它们都想以/api 开头，但彼此没有任何关系。

控制器在那里接收和控制交易，如果他们只关心这些，那就更好了。更好通常意味着“我必须少输入才能找到我想要的文件”。但是，这也意味着模型不应该绑定到任何特定的控制器。一个好的模型应该是独立的和可重用的。这就是他们分离关注点的重点。

- App
    - Controller
      - MajorPartOfApp
        - ...
      - UnrelatedPartOfApp
        - ...
    - Model
      - NotTiedToAnyController
      - StillNotTiedToAnyController

当模型不是独立的，并且它是专门为特定的控制器（或一组控制器）服务时，重用变得混乱。我宁愿拥有通用模型。假设您为应用程序添加了另一个主要部分，但现有控制器中的模型可以处理它。现在命名约定被打破了，因为您正在访问与您的任务无关的命名空间。或者，我看到人们创建了使用相同源但具有不同界面的其他模型。这重复了代码。

顺便说一句：当您谈论代码可读性时，请忘记语法和语句。我会用一些难以理解的代码来换取更好的项目结构，这样我就不必在奇怪的地方寻找我应该使用的代码。例如，当我需要和狗一起做事时，为什么要查看 CatStuff.pm？糟糕的架构和组织对我来说更痛苦。

我倾向于喜欢命令行程序，所以我喜欢从终端执行 Web 应用程序启用的相同任务。而且，这是代码分离的真正测试。我可以使用相同的组件来制作终端工具吗？如果控制器和模型是轻量级包装器，这意味着我可以轻松地将它们包装的东西用于完全不同的非 Mojo 项目。如果我不能轻易做到这一点，我可能让控制器或模型太复杂了。

制作新工具应该更容易，而不是更难。这就是“选项三角形”。如果我的选择范围缩小（因此，接近三角形的尖端部分）我越深入项目，我可能做错了事情。如果我的选择范围扩大，我可能会做得更好。

通常的反对意见是这些东西永远不会相互影响。那么，这就是代码管理和部署的问题。如果它们真的是两个独立的东西，我希望它们实际上是独立的。不过，我并不总是如愿以偿（也许甚至通常都不会；）也许你也不如意。

【讨论】：