ginkgo


架构概况

ginkgo 应用基于 MVC(模型-视图-控制器)的方式来组织。

MVC 是一种开发模式,它强制性的使应用程序的输入、处理和输出分开。使用 MVC 的应用被分成三个核心部分:模型(Model)、视图(View)、控制器(Controller),它们各自处理自己的任务。

ginkgo 的 URL 访问受路由决定,如果没有匹配的路由规则,则是基于默认路由,例如:

http://server/index.php/模块/控制器/动作/参数-1/值-1/参数-2/值-2...

下面的一些概念有必要做下了解,可能在后面的内容中经常会被提及。


入口文件

用户发起请求的 PHP 文件,负责统一处理请求,最常见的入口文件就是 index.php,有时候也会因为特殊需求而增加、改变入口文件,例如给后台模块单独设置的一个入口文件 admin.php


应用

应用在 ginkgo 中是一个具有实际可操作的对象,应用通常在入口文件中被调用和执行,具有相同目录的应用 GK_PATH_APP 认为是同一个应用,但一个应用可以存在多个入口文件。

应用具有自己独立的配置文件、公共(函数)文件。


模块

一个典型的应用是由多个模块组成的,每个模块都有自己独立的配置文件、语言文件、公共文件和类库文件等。但是模块在 ginkgo 的目录结构中是相对零散的,比如后台模块的控制器位于 ./app/ctrl/admin 目录,配置文件位于 ./app/config/admin/


控制器

一个模块下面有多个控制器负责响应请求,而每个控制器其实就是一个独立的控制器类。控制器主要负责请求的接收,并调用相关的模型进行处理,最终通过视图输出。严格来说,控制器不应该过多的介入业务逻辑处理。

事实上在 ginkgo 的控制器是可以被跳过的,通过路由可以直接把请求调度到其他的控制器进行处理。

一个典型的 Index 控制器类如下:

namespace app\ctrl\index;

class Index {
    public function index() {
        return 'hello, world!';
    }
}

动作

一个控制器包含多个动作(方法),动作是一个 URL 访问的最小单元。

下面是一个典型的 Index 控制器的动作定义,包含了两个动作:

namespace app\ctrl\index;

class Index {
    public function index() {
        return 'hello, world!';
    }

    public function hello($name) {
        return 'Hello, ' . $name;
    }
}

模型

模型类通常完成实际的业务逻辑和数据封装,并返回和格式无关的数据。模型类并不一定要访问数据库。

ginkgo 的模型层支持多层设计,可以对模型层进行更细化的设计和分工,例如把模型层分为 逻辑层 / 服务层 / 事件层 等等。


视图

控制器调用模型类后返回的数据通过视图组装成不同的格式输出。视图根据不同的需求,来决定调用视图驱动进行内容解析后输出还是直接输出。

视图通常会有一系列的模板文件对应不同的控制器和动作,并且支持动态设置模板目录。


验证器

验证器是基于框架内置的验证类 Validate,为具体的验证场景或者数据事先定义好的验证类。验证器直接调用验证类的 verify 方法完成验证。