企业🤖AI Agent构建引擎,智能编排和调试,一键部署,支持私有化部署方案 广告
ThinkPHP 简单强大, 但提供的功能毕竟还是有限的. 好在在开源世界为我们提供了取之不竭的资源, 恰到好处地使用第三方资源, 可以大大降低我们的开发成本, 节约开发时间. 几乎所有流行的语言, 都有自己的包管理工具, 方便用户之间自由分享自己的成功, 促进社区的共同繁荣. Python 有pip, Ruby有gem, NodeJs有npm ... PHP 有 Composer. 通过它, 你可以轻松将其他人已经发布到 packagist.org 的 composer 包集成到自己的项目中. 当安装了一个composer包之后, 包提供的类和函数在你的项目中都立即可用! 记住: 你越善于使用前人的成果, 你就可以比别人跑的更快, 站得更高, 看的更远. 人类的科技进步史, 已经证明了这点, 积极拥抱composer, 拒绝等于落后. * Composer 官网: https://getcomposer.org/ * Packgist 官网: https://packgist.org/ 接下来, 我要介绍几个有用的composer包, 让我们从问题开始: ## 问题: 环境隔离 真实世界的开发往往是这样, 多个团队成员共同开发, 线上线下的代码通过版本控制系统保持一致. 但你无法保证也没理由要求所有机器上的应用配置一致. 例如,要求所有成员使用相同的本地数据库用户名和密码是不合理的. 线上线下使用相同的数据库配置更加不合理. 我们有很多种方式避免这种问题, 一种常见的方法是, 将配置文件重命名为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 ## 问题: 日志管理 开发阶段的日志管理很简单, 甚至很多人认为不重要. 但生产环境中, 如果你轻视日志管理, 代价可能是巨大的. 日志记录了应用的历史, 历史可以诏示未来. 分析海量日志, 你可以得出很多很重要的信息, 这些信息可以帮助你提升性能,避免瓶颈,及时扩容,发现攻击,修补漏洞.... 但TP的日志功能, 非常简单, 也许无法担当重任. 试想一下, 当你发展到需要十台服务器在负载均衡下运行应用时, 你该如何管理你的日志? 或者, 线上代码出现了随机偶发性的问题, 本地几乎不可能重现这些问题,你该如何捕捉信息? 还有很多情况,需要有一个趁手的日志工具帮助你解决问题. monolog是 Packgist上最流行的日志库, 在 composer 约7万余个包中, 它的安装量排名第一. 它也是symfony和laravel默认集成的日志库. 它之所以流行, 在于它功能丰富可以满足各种层次的需要,而且易于集成至其他系统,并且简单好用. **think-monolog** 包完成了将monolog集成至TP的工作, 所以在TP项目中, 你只需要这样使用: ``` composer require snowair/think-monolog:dev-master ``` 代码中: ``` \Snowair\Think\Logger::debug('这是一条debug日志'); ``` * GitHub项目地址: https://github.com/snowair/think-monolog.git ### 问题: 单元测试 你的项目越复杂庞大, 可能约需要单元测试. 为独立的类写单元测试是件轻松愉快的事情, 但为存在耦合的类写单元测试就不那么爽快了. 因此, 如果要实施单元测试, 您的代码需要写的适合做单元测试. 但有些情景,你可能无能为力: 在TP中, 你的控制器类必须继承`Think\Controller`类,你的模型类必须继承`Think\Model`类. 而这两个类中相当的逻辑, 与TP的生命周期密切耦合. 要测试它们, 你首先需要模拟出应用的执行过程, 创建出它们所需要的那些耦合的元素, 否则它们无法正常执行. 所以, 大多情况, 我们会忽略对这俩种类的测试或只做有限的测算. **think-phpunit** 的目标是帮助你对控制器和模型类做完整测试, 并且将这一过程简单化. 首先, 为了让phpunit能载入你的类, 你必须修改项目的 composer.json: ``` { "name": "公司名/项目名", "autoload": { "classmap": ["Application","ThinkPHP/Library"] } } ``` 然后安装: ``` composer require snowair/think-phpunit:dev-master ``` 接下来,我创建了一个 `./test/IndexControllerTest.php` 测试类: ``` <?php class IndexControllerTest extends PhpUnit { static public function setupBeforeClass() { // 下面四行代码模拟出一个应用实例, 每一行都很关键 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 for TP, GitHub项目地址: https://github.com/snowair/think-twig.git * whoops for TP, GitHub项目地址: https://github.com/snowair/think-whoops.git