架构概况

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

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

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

  1. 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 控制器类如下：

  1. namespace app\ctrl\index;
  3. class Index {
  4.     public function index() {
  5.         return 'hello, world!';
  6.     }
  7. }
动作

一个控制器包含多个动作（方法），动作是一个 URL 访问的最小单元。

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

  1. namespace app\ctrl\index;
  3. class Index {
  4.     public function index() {
  5.         return 'hello, world!';
  6.     }
  8.     public function hello($name) {
  9.         return 'Hello, ' . $name;
  10.     }
  11. }
模型

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

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

视图

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

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

验证器

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