传统的MVC模式提倡为MCL模式

传统的MVC模式包含model-view-controller层,绝大多时候我们会把业务逻辑写到controller层或model层,但是慢慢的我们会发现代码难以阅读、维护、扩展,所以我在这里强制增加了一个logics层。至于,逻辑层里怎么写代码怎么,完全由你自己定义,你可以在里面实现一个工具类,你也可以在里面再新建子文件夹并在里面构建你的业务逻辑代码,你甚至可以实现一个基于责任连模式的网关(我会提供具体的示例)。这样看来,我们的最终结构是这样的:

  • M: models, 职责只涉及数据模型相关操作
  • C: controllers, 职责对外暴露资源,前后端分离架构下controllers其实就相当于json格式的视图
  • L: logics, 职责灵活实现所有业务逻辑的地方

logics逻辑层

逻辑层实现网关示例:

我们在logics层目录下增加了一个gateway目录,然后我们就可以灵活的在这个目录下编写逻辑了。gateway的结构如下:

gateway                     [Logics层目录下gateway逻辑目录]
├── Check.php [接口]
├── CheckAppkey.php [检验app key]
├── CheckArguments.php [校验必传参数]
├── CheckAuthority.php [校验访问权限]
├── CheckFrequent.php [校验访问频率]
├── CheckRouter.php [网关路由]
├── CheckSign.php [校验签名]
└── Entrance.php [网关入口文件]

网关入口类主要负责网关的初始化,代码如下:

// 初始化一个:必传参数校验的check
$checkArguments = new CheckArguments();
// 初始化一个:app key check
$checkAppkey = new CheckAppkey();
// 初始化一个:访问频次校验的check
$checkFrequent = new CheckFrequent();
// 初始化一个:签名校验的check
$checkSign = new CheckSign();
// 初始化一个:访问权限校验的check
$checkAuthority = new CheckAuthority();
// 初始化一个:网关路由规则
$checkRouter = new CheckRouter();

// 构成对象链
$checkArguments->setNext($checkAppkey)
->setNext($checkFrequent)
->setNext($checkSign)
->setNext($checkAuthority)
->setNext($checkRouter);

// 启动网关
$checkArguments->start(
APP::$container->getSingle('request')
);

实现完成这个gateway之后,我们如何在框架中去使用呢?在logic层目录中我提供了一个user-defined的实体类,我们把gateway的入口类注册到UserDefinedCase这个类中,示例如下:

/**
* 注册用户自定义执行的类
*
* @var array
*/
private $map = [
// 演示 加载自定义网关
'App\Demo\Logics\Gateway\Entrance'
];

这样这个gateway就可以工作了。接着说说这个UserDefinedCase类,UserDefinedCase会在框架加载到路由机制之前被执行,这样我们就可以灵活的实现一些自定义的处理了。这个gateway只是个演示,你完全可以天马行空的组织你的逻辑~

视图View去哪了?由于选择了完全的前后端分离和SPA(单页应用), 所以传统的视图层也因此去掉了,详细的介绍看下面。

[file: app/*]

使用Vue作为视图

源码目录

完全的前后端分离,数据双向绑定,模块化等等的大势所趋。这里我把我自己开源的vue前端项目结构easy-vue移植到了这个项目里,作为视图层。我们把前端的源码文件都放在frontend目录里,详细如下,你也可以自己定义:

frontend                        [前端源码和资源目录,这里存放我们整个前端的源码文件]
├── src [资源目录]
│ ├── components [编写我们的前端组件]
│ ├── views [组装我们的视图]
│ ├── images [图片]
│ ├── ...
├── app.js [根js]
├── app.vue [根组件]
├── index.template.html [前端入口文件模板]
└── store.js [状态管理,这里只是个演示,你可以很灵活的编写文件和目录]

build步骤

yarn install

DOMAIN=http://你的域名 npm run dev

编译后

build成功之后会生成dist目录和入口文件index.html在public目录中。非发布分支.gitignore文件会忽略这些文件,发布分支去除忽略即可。

public                          [公共资源目录,暴露到万维网]
├── dist [前端build之后的资源目录,build生成的目录,不是发布分支忽略该目录]
│ └── ...
├── index.html [前端入口文件,build生成的文件,不是发布分支忽略该文件]

[file: frontend/*]

数据库对象关系映射

数据库对象关系映射ORM(Object Relation Map)是什么?按照我目前的理解:顾名思义是建立对象和抽象事物的关联关系,在数据库建模中model实体类其实就是具体的表,对表的操作其实就是对model实例的操作。可能绝大多数的人都要问“为什么要这样做,直接sql语句操作不好吗?搞得这么麻烦!”,我的答案:直接sql语句当然可以,一切都是灵活的,但是从一个项目的可复用,可维护, 可扩展出发,采用ORM思想处理数据操作是理所当然的,想想如果若干一段时间你看见代码里大段的难以阅读且无从复用的sql语句,你是什么样的心情。

市面上对于ORM的具体实现有thinkphp系列框架的Active Record,yii系列框架的Active Record,laravel系列框架的Eloquent(据说是最优雅的),那我们这里言简意赅就叫ORM了。接着为ORM建模,首先是ORM客户端实体DB:通过配置文件初始化不同的db策略,并封装了操作数据库的所有行为,最终我们通过DB实体就可以直接操作数据库了,这里的db策略目前我只实现了mysql(负责建立连接和db的底层操作)。接着我们把DB实体的sql解析功能独立成一个可复用的sql解析器的trait,具体作用:把对象的链式操作解析成具体的sql语句。最后,建立我们的模型基类model,model直接继承DB即可。最后的结构如下:

├── orm                         [对象关系模型]
│ ├── Interpreter.php [sql解析器]
│ ├── DB.php [数据库操作类]
│ ├── Model.php [数据模型基类]
│ └── db [数据库类目录]
│ └── Mysql.php [mysql实体类]

DB类使用示例

/**
* DB操作示例
*
* findAll
*
* @return void
*/
public function dbFindAllDemo()
{
$where = [
'id' => ['>=', 2],
];
$instance = DB::table('user');
$res = $instance->where($where)
->orderBy('id asc')
->limit(5)
->findAll(['id','create_at']);
$sql = $instance->sql;

return $res;
}

Model类使用示例

// controller 代码
/**
* model example
*
* @return mixed
*/
public function modelExample()
{
try {

DB::beginTransaction();
$testTableModel = new TestTable();

// find one data
$testTableModel->modelFindOneDemo();
// find all data
$testTableModel->modelFindAllDemo();
// save data
$testTableModel->modelSaveDemo();
// delete data
$testTableModel->modelDeleteDemo();
// update data
$testTableModel->modelUpdateDemo([
'nickname' => 'easy-php'
]);
// count data
$testTableModel->modelCountDemo();

DB::commit();
return 'success';

} catch (Exception $e) {
DB::rollBack();
return 'fail';
}
}

//TestTable model
/**
* Model操作示例
*
* findAll
*
* @return void
*/
public function modelFindAllDemo()
{
$where = [
'id' => ['>=', 2],
];
$res = $this->where($where)
->orderBy('id asc')
->limit(5)
->findAll(['id','create_at']);
$sql = $this->sql;

return $res;
}

[file: framework/orm/*]

服务容器模块

什么是服务容器?

服务容器听起来很浮,按我的理解简单来说就是提供一个第三方的实体,我们把业务逻辑需要使用的类或实例注入到这个第三方实体类中,当需要获取类的实例时我们直接通过这个第三方实体类获取。

服务容器的意义?

用设计模式来讲:其实不管设计模式还是实际编程的经验中,我们都是强调“高内聚,松耦合”,我们做到高内聚的结果就是每个实体的作用都是极度专一,所以就产生了各个作用不同的实体类。在组织一个逻辑功能时,这些细化的实体之间就会不同程度的产生依赖关系,对于这些依赖我们通常的做法如下:

class Demo
{
public function __construct()
{
// 类demo直接依赖RelyClassName
$instance = new RelyClassName();
}
}

这样的写法没有什么逻辑上的问题,但是不符合设计模式的“最少知道原则”,因为之间产生了直接依赖,整个代码结构不够灵活是紧耦合的。所以我们就提供了一个第三方的实体,把直接依赖转变为依赖于第三方,我们获取依赖的实例直接通过第三方去完成以达到松耦合的目的,这里这个第三方充当的角色就类似系统架构中的“中间件”,都是协调依赖关系和去耦合的角色。最后,这里的第三方就是所谓的服务容器。

在实现了一个服务容器之后,我把Request,Config等实例都以单例的方式注入到了服务容器中,当我们需要使用的时候从容器中获取即可,十分方便。使用如下:

// 注入单例
App::$container->setSingle('别名,方便获取', '对象/闭包/类名');

// 例,注入Request实例
App::$container->setSingle('request', function () {
// 匿名函数懒加载
return new Request();
});
// 获取Request对象
App::$container->getSingle('request');

[file: framework/Container]

Nosql模块

提供对nosql的支持,提供全局单例对象,借助我们的服务容器我们在框架启动的时候,通过配置文件的配置把需要的nosql实例注入到服务容器中。目前我们支持redis/memcahed/mongodb。

如何使用?如下,

// 获取redis对象
App::$container->getSingle('redis');
// 获取memcahed对象
App::$container->getSingle('memcahed');
// 获取mongodb对象
App::$container->getSingle('mongodb');

[file: framework/nosql/*]

接口文档生成和接口模拟模块

通常我们写完一个接口后,接口文档是一个问题,我们这里使用Api Blueprint协议完成对接口文档的书写和mock(可用),同时我们配合使用Swagger通过接口文档实现对接口的实时访问(目前未实现)。

Api Blueprint接口描述协议选取的工具是snowboard,具体使用说明如下:

接口文档生成说明

cd docs/apib

./snowboard html -i demo.apib -o demo.html -s

open the website, http://localhost:8088/

接口mock使用说明

cd docs/apib

./snowboard mock -i demo.apib

open the website, http://localhost:8087/demo/index/hello

[file: docs/*]

单元测试模块

基于phpunit的单元测试,写单元测试是个好的习惯。

如何使用?

tests目录下编写测试文件,具体参考tests/demo目录下的DemoTest文件,然后运行:

vendor/bin/phpunit

测试断言示例:

/**
* 演示测试
*/
public function testDemo()
{
$this->assertEquals(
'Hello Easy PHP',
// 执行demo模块index控制器hello操作,断言结果是不是等于'Hello Easy PHP' 
App::$app->get('demo/index/hello')
);
}

phpunit断言文档语法参考

[file: tests/*]

Git钩子配置

目的规范化我们的项目代码和commit记录。

  • 代码规范:配合使用php_codesniffer,在代码提交前对代码的编码格式进行强制验证。
  • commit-msg规范:采用ruanyifeng的commit msg规范,对commit msg进行格式验证,增强git log可读性和便于后期查错和统计log等, 这里使用了Treri的commit-msg脚本,Thx~。

[file: ./git-hooks/*]

辅助脚本

cli脚本

以命令行的方式运行框架,具体见使用说明。

build脚本

打包PHP项目脚本,打包整个项目到runtime/build目录,例如:

runtime/build/App.20170505085503.phar

<?php
// 入口文件引入包文件即可
require('runtime/build/App.20170505085503.phar');

[file: ./build]

如何使用?

执行:

  • composer install
  • chmod -R 777 runtime

网站服务模式:

步骤 1: yarn install
步骤 2: DOMAIN=http://localhost:666 npm run demo
步骤 3: cd public
步骤 4: php -S localhost:666

访问网站:http://localhost:666/index.html
访问接口:http://localhost:666/Demo/Index/hello

客户端脚本模式:

php cli --method=<module.controller.action> --<arguments>=<value> ...

例如, php cli --method=demo.index.get --username=easy-php

获取帮助:

使用命令 php cli 或者 php cli –help