ThinkPHP开发必备composer扩展包

本文介绍几个有助于提高开发效率和质量的ThinkPHP专用composer包, 它们都是packgist上最流行的composer包为与ThinkPHP进行无缝集成而特别封装. 安装后, 无需修改框架源码, 无需或仅需修改一下配置文件, 便立即可用.

本文假设读者有能力正常使用composer

环境隔离 dotenv

真实世界的开发往往是这样, 多个团队成员共同开发, 线上线下的代码通过版本控制系统保持一致.

但你无法保证也没理由要求所有机器上的应用配置一致. 例如,要求所有成员使用相同的本地数据库用户名和密码是不合理的.

线上线下使用相同的数据库配置更加不合理.

我们有很多种方式避免这种问题, 一种常见的方法是, 将配置文件重命名为config.example.php, 然后在每个部署的环境再重命名为config.php,并在分发时排除这个文件.

这种方法很容易实现,但缺点是他是静态的. 每当你增加了一项配置, 或者减少了一项配置, 都需要告诉别人手动处理config.php. 否则, 它的程序可能无法正常运行.

通过专门的环境配置区分不同的部署环境,是另一种被广泛采用的方案. 它的原理很简单: 不同的部署环境中, 需要区别的配置往往非常有限, 所有将config.php纳入版本控制或者分发包中更合理.

这样config.php有变化时,其他环境中的应用可以第一时间更新. 那有限的几个有环境有关配置, 往往都是诸如数据库配置这种必不可少的. 将它们单独隔离出来更加合理. 通常, 实施这种方案会把

隔离的配置放在一个名为

.env

的文件中. 因此这种方案, 称为 DotEnv.

Packgist.org 中的 php-dotenv 是一个非常棒的包, 很适合与TP集成. think-dotenv 包已经完成了集成, 所以你可以拿来就用:

composer require snowair/think-dotenv:dev-master

修改 Common/Conf/tags.php

return array( 'app_init'=>array( 'Snowair\Think\Behavior\HookAgent' ) )

在项目根目录下创建

.env

文件, 配置内容以 key=value 的格式逐行书写,例如:

DB_HOST=localhost
DB_NAME=test
DB_USER=root
DB_PWD=root

这样, 应用运行时, 上面四项配置将生效覆盖config.php中的配置. 不同的部署环境, 只需要创建自己的.env文件, 相互之间就实现了环境隔离.

GitHub项目地址: https://github.com/snowair/think-dotenv.git

全功能日志 monolog

开发阶段的日志管理很简单, 甚至很多人认为不重要. 但生产环境中, 如果你轻视日志管理, 代价可能是巨大的. 日志记录了应用的历史, 历史可以诏示未来.

分析海量日志, 你可以得出很多很重要的信息, 这些信息可以帮助你提升性能,避免瓶颈,及时扩容,发现攻击,修补漏洞….

但TP的日志功能, 非常简单, 也许无法担当重任. 试想一下, 当你发展到需要十台服务器在负载均衡下运行应用时, 你该如何管理你的日志?

或者, 线上代码出现了随机偶发性的问题, 本地几乎不可能重现这些问题,你该如何捕捉信息? 还有很多情况,需要有一个趁手的日志工具帮助你解决问题.

monolog是 Packgist上最流行的日志库, 在 composer 约7万余个包中, 它的安装量排名第一. 它也是symfony和laravel默认集成的日志库. 它之所以流行, 在于它功能丰富可以满足各种层次的需要,而且易于集成至其他系统,并且简单好用.

think-monolog 包完成了将monolog集成至TP的工作, 所以在TP项目中, 你只需要这样使用:

composer requrie snowair/think-monolog:dev-master

代码中:

\Snowair\Think\Logger::debug('这是一条debug日志');

GitHub项目地址: https://github.com/snowair/think-monolog.git

敏捷利器 phpunit

你的项目越复杂庞大, 可能约需要单元测试. 为独立的类写单元测试是件轻松愉快的事情, 但为存在耦合的类写单元测试就不那么爽快了.

因此, 如果要实施单元测试, 您的代码需要写的适合做单元测试. 但有些情景,你可能无能为力: 在TP中, 你的控制器类必须继承

Think\Controller

类,你的模型类必须继承

Think\Model

类. 而这两个类中相当的逻辑, 与TP的生命周期密切耦合.

要测试它们, 你首先需要模拟出应用的执行过程, 创建出它们所需要的那些耦合的元素, 否则它们无法正常执行. 所以, 大多情况, 我们会忽略对这俩种类的测试或只做有限的测算.

think-phpunit 的目标是帮助你对控制器和模型类做完整测试, 并且将这一过程简单化.

首先, 为了让phpunit能载入你的类, 你必须修改项目的 composer.json:

{
"name": "公司名/项目名",
"autoload": {
"classmap": ["Application","ThinkPHP/Library"]
}
}

然后安装:

composer requrie snowair/think-phpunit:dev-master

接下来,我创建了一个

./test/IndexControllerTest.php

测试类:

<?php
class IndexControllerTest extends PhpUnit
{

static public function setupBeforeClass()<
4000
/span>
{
// 下面四行代码模拟出一个应用实例, 每一行都很关键
parent::$app = new \Think\PhpunitHelper();
parent::$app->setMVC('domain.com','Home','Index');
parent::$app->setTestConfig(['DB_NAME'=>'test', 'DB_HOST'=>'127.0.0.1',]);
parent::$app->start();
}

public function testIndex()
{
$output = $this->execAction('index');
$this->assertEquals('hello world',$output);
}
}

然后执行:

$ vendor/bin/phpunit test/IndexControllerTest.php
PHPUnit 4.8.6 by Sebastian Bergmann and contributors.

.

Time: 139 ms, Memory: 7.00Mb

OK (1 test, 1 assertion)

就是如此轻松.

GitHub项目地址: https://github.com/snowair/think-phpunit.git

优雅模板 Twig引擎

相比ThinkPHP内置的Think模板引擎, Twig引擎拥有更优雅的语法, IDE的对其支持更好. 并且,使用独立的Twig引擎开发模板有助于未来的移植: 当项目决定迁移至Laravel或Symfony时, 模板可以原封不动的保留.

composer require snowair/think-twig:dev-master

引擎配置:

/* Twig模板引擎设置 */
'TMPL_ENGINE_TYPE'      =>  'Twig',      // 设置为Twig启用twig引擎
'TMPL_TEMPLATE_SUFFIX'  =>  '.html',     // 设置模板后缀, 可自由设置ACTION_NAME之间的分割符

做完上面的配置, twig就生效了

twig for TP, GitHub项目地址: https://github.com/snowair/think-twig.git

优雅异常 Whoops

当系统抛出异常, 我们需要一个工具, 立即在页面显示出异常栈的全过程,Whoops是这方面做的最好的工具.

composer require snowair/think-whoops:dev-master

在 Common/Conf/tags.php 增加一个行为,如果之前已经添加过,就不用再添加了:

return array(

'app_init'=>array(

'Snowair\Think\Behavior\HookAgent'

),

)

就是这么简单, whoops立即生效了!

whoops for TP, GitHub项目地址: https://github.com/snowair/think-whoops.git