刚学php的时候第一次遇到phalcon，最近终于有机会用了。那么我们来谈谈使用它的一些感受。

个人非常喜欢phalcon的框架，使用依赖注入使得代码组织非常灵活，耦合性非常低。但是，可能是框架里东西太多，遇到了几个坑。github一年多的问题还没有解决。不过，如果你有一些开发经验，还是可以自己修复的。这些坑浪费了很多时间。

首先是观点。

phalcon的视图可以分为两部分，一部分是全局布局，另一部分是控制器/动作部分，使用起来更加方便。设置布局后，只注意控制器部分的视图。但是关于视图的路径设置，我们要注意这些参数：MainView(主布局文件的路径文件名，但不包括扩展名，扩展名是注入视图引擎时的键值)。

布局目录(布局的目录路径)，

布局(主布局的文件名，可根据需要动态使用布局目录中的文件作为mainView)，

partialsDir(使用PartialsDir函数时，搜索模板文件，例如，PartialsDir(' main/header ')，搜索路径为'/your PartialsDir/main/header . volt '。),

ViewsDir(设置对应控制器/动作的模板文件所在的目录。与partialDir类似，自动搜索目录下的模板文件)。

BasePath(视图的目录的基本目录，phalcon和dir根据所有设置来组合路径，找到模板文件，而这就是pit)。

当我第一次开始使用这个视图时，我使用了绝对路径，因为配置和管理绝对路径很方便。然后就卡住了，浪费了一个下午调试。根据官方文档中给出的例子反复测试后发现，这个视图组件只能使用相对路径来设置路径，不需要设置BasePath。

一气之下，我求助于phalcon的源代码。开发语言是zephir，由phalcon团队开发。

语言简单易懂。然后我看到了这句话。

.]

似乎没有判断是相对路径还是绝对路径，而是直接组合在一起。我猜是这里引起了问题。

动作、布局、主布局等模板文件直接按顺序解析。

所以我想验证一下。所以我写了几个调试文件，打算调试一下。

搜索phalcon源代码的过程省略了1000个单词.并找到几个将被调用并进行路径处理的主要方法，并继承几个与View相关的类。

这里还要强调一点，很多人都喜欢用echo，一般都可以，但是最好还是记录在文件里，因为echo有很大的局限性，你不知道echo buff什么时候会开，什么时候会关。使用文件记录日志是最安全的。我测试的代码使用了多模块方法。

基础文件，继承phalcon的视图，并打开该方法的错误消息。

BaseVolt文件，继承自模板引擎Volt。

注射代码和目录结构的视图图。

日志记录如下。

输出页面如下：

正如想象的那样，当使用绝对路径时，phalcon无论如何都会直接拼接上面设置的路径。

当开发人员想动态使用controller/action的视图，但是layouts主目录在上层目录时，就会出现问题。

phalcon找到的主布局路径是phal con MVC view exception : view '/user/hin/work/phal con _ mode/app/modules/admin/view/layouts/main '在view目录中找不到。

我想要/用户/hin/工作/p halcon _ mode/app/视图/布局/main。

然后，如果找不到路径，主布局模板文件将不起作用。.

因此，它实际上只是三条路径的直接组合.所以，在设置路径的时候，就要看你自己的选择了。在phalcon视图源代码中的三个变量中，basePath、viewDir(关键是作者误解了变量viewDir。作为基本路径。viewPath是依次执行_enginrender时ActionView、LayoutView和MainView的路径。明白这一点后，你可以自己慢慢设定路径。

有三种解决方案。首先，自己写一个View来继承phalcon的View并处理路径。这个想法是，除了动作的定位之外，其他定位会将viewDir更改为null。第二，修改phalcon的源代码，自己重新编译(处理_enginRender外的路径定位，去掉_enginRender与路径定位的耦合)。第三，忽略它。直接使用相对路径(不设置basepath，由于动作视图的动态定位，viewsDir使用绝对路径，layoutsDir partialsDir使用相对路径)。有人在github上发布了这个bug的问题，但是作者忽略了。

第二个是模特。

还有一个关于phalcon模型的坑。同样的问题也发出了，但提交人没有理会。根据文档模型，提供了setter链接描述方法，但实际上，setter不起作用。

然后，像view一样，自己修复它.。

我个人觉得setter getter是一个很有用的功能，但是有人觉得没用。我们的开发模式是模型和控制器由不同的人开发。使用setter getter，数据调用者只需要获取数据。如果模型数据有问题，他们可以在模型中修改。不需要更换控制器。工作模式下的耦合可以大大减少。但是使用这个框架的开发项目流产了，更深的坑也不会遇到。如果没有意外，短期内不会使用。最近心情比较不好。随便写。成为记录。

最后，直接附上github源代码。用这种目录结构进行多模块模式开发也不错，希望对其他人有所帮助。