phalcon - 使用 Phalcon 命名空间

Question

我所有的 Controller 都在命名空间 MyApp\Controllers 下因此，正如文档所推荐的那样，我已将默认命名空间设置为:

$dispatcher->setDefaultNamespace('MyApp\Controllers');

但现在我不仅需要在文件夹中组织我的 Controller ，还需要命名它们并具有友好的 URL，例如: /features/featureX/和 /wizards/featureX/ .所以从那个例子中我得到了 MyApp\Controllers\Features\FeaturesX和 MyApp\Controllers\Wizards\FeaturesX .

我认为它们不应该被视为模块，对吗？它们只是一些自定义路由，但从路由文档中我不知道如何:

声明一个只定义命名空间的路由(例如 $router->add("/:namespace", ["namespace" => 1]); )

使上述路由策略仅用于某些 Controller 。例如，LoginController ，应保留在 MyApp\Controllers命名空间。

也许我可以通过为每个路由器或调度程序使用一个路由器或调度程序来实现这一点。任何有经验的 Phalcon 开发人员都可以在这里给我一个提示吗？!

Answer 1

好吧，在使用 Phalcon 一段时间后，我可以说有时当您决定使用与我们在项目文档中找到的方法不同的方法时，它并不那么灵活。 namespace 的使用是这些情况之一。
框架不能很好地处理多个命名空间级别，但它仍然设计良好且可扩展。您几乎可以覆盖任何内容，并且通过一些自定义，您可以实现您想要的任何行为。
以下是我为在文件夹/命名空间中组织我的所有内容并仍然使用整个框架所做的工作。
其中一些信息可能对您的上下文有用，因此这是迄今为止我的传奇旅程的报告......
Phalcon 与命名空间
好的，所以如果您决定将 PHP 源代码组织在文件夹和命名空间内，请准备好调整几乎所有主要功能，并准备好 更多在您的实现中明确(即在任何地方使用完整的类路径)。
基本上，您将丢弃框架必须提供的一些最酷的自动化，因为它们是基于约定的，并且这些约定似乎是在没有考虑 namespace 的情况下定义的。
但是，尽管有这些额外的工作要做，我还是决定保留这个设计决定；毕竟，我们选择 MVC 框架是有原因的，对吧？!我们想让事情井井有条。特别是在大型项目中，将源代码稀释到多个命名空间/文件中以提高可维护性非常重要。

目录结构
首先，您应该了解我选择的目录结构，以了解我在下面谈论的内容。相信我，我已经花了几个小时来调整这个结构并阅读其他 MVC 框架推荐的结构，毕竟我个人的建议非常简单:选择问题较少的!通常，这意味着更加解耦/碎片化的一个。
这是我目前使用的结构，它已经为我服务了将近两年，并且适合我需要抛出的任何类型的代码:

清楚地了解您的目录/命名空间结构可以在实现新内容时消除大量猜测，并帮助您在不知不觉中编写解耦代码。如果你在一开始就“浪费”了一些时间来关心这个，这意味着将来你的重构不会那么痛苦。

类加载器
你注意到 source/文件夹及其内容或多或少地组织为 PSR Standards需要？!
造成这种情况的原因是 Phalcon's Class Loader符合 PSR-0；
所以基本上我只需要注册 source/文件夹到加载器:

$phLoader = new PhLoader();
// Considering the public folder as your current __DIR__
$phLoader->registerDirs(['../source/']);
$phLoader->register();

……瞧!您只需引用该类(需要时使用完整路径)，PHP 和 Phalcon 内部实现都会找到它。例如，要在我的 DI 容器中注册我的组件之一:

// At the first time the service 'foo' is needed
// Phalcon will read the file at 'source/MyApp/Components/Foo.php'
// and then call Foo's constructor
$di->set('foo', 'MyApp\Components\Foo'); 

路由器和 Controller
如果您的所有 Controller 都在同一个命名空间/文件夹中，您可以简单地执行以下操作:

$router->setDefaultNamespace('MyApp\Controllers');

好的!
但是如果您在 MyApp\Controllers\Foo\BarController 下有一个 Controller 怎么办？ ？!
就像默认的加载器行为一样，路由器无需尝试解释 Foo部分作为另一个命名空间级别。
ATTOW 没有解决方法可以让路由器在“更深”的命名空间中找到 Controller 。到目前为止，我的解决方案是关闭 default routing behavior并手动添加 四种常见模式为 每个命名空间分支 .
“四种常见模式”是指这些路线: :namespace/index/index仅定义命名空间时 :namespace/:controller/index/仅定义命名空间和 Controller 名称时 :namespace/:controller/:action/定义命名空间、 Controller 和 Action 名称时 :namespace/:controller/:action/:params当一切都被定义并包括参数时
为了为所有命名空间启用这些路由，我替换了 :namespace正则表达式占位符与另一个匹配所有可能命名空间的正则表达式，并实现了一个“转换器”，将路由转换为正确的命名空间(即 "/foo/bar/baz"--> ['namespace' => 'MyApp\Controllers\Foo', 'controller' => 'bar', 'action' => 'baz'] )。
只是为了说明我在这里谈论的是我前段时间写的一个自定义路由器，并使用了这种技术:
https://gist.github.com/snolflake/9797835

楷模
你必须遵循什么 the docs say .这意味着，任何时候您在 PHQL 上提及模型时(或关系定义)您需要始终使用完整的类路径。
观看次数
我所说的 View 基本上是指模板文件。当然，它们不在 namespace 下，但由于您的 Controller 在 namespace 下，因此自动选择 View 无法正常工作。所以你的意见应该手动选择:

namespace MyApp\Controllers\Foo;

class BarController
{
    public function bazAction()
    {
        // The path is relative to the views dir you've set before
        $this->view->pick('configurations/subscriptions/index.volt')
        ...

很高兴您可以利用该事件 beforeExecuteRoute根据您自己的约定自动选择 View 。
结论
似乎 Phalcon 的目标更多是简单/琐碎的项目，但这完全合理，即使使用所有这些样板代码让您的应用程序更加花哨，框架本身的其余部分也使以后的工作变得值得。
同时我只希望下一个版本包含更多命名空间友好的功能。