堂堂糖唐

堂堂糖唐 查看完整档案

成都编辑  |  填写毕业院校聚美优品  |  PHP高级工程师 编辑 www.tbphp.net 编辑
编辑

最帅的程序员

个人动态

堂堂糖唐 评论了文章 · 2018-12-25

理解vue ssr原理,自己搭建简单的ssr框架

前言

大多数Vue项目要支持SSR应该是为了SEO考虑,毕竟对于WEB应用来说,搜索引擎是一个很大的流量入口。Vue SSR现在已经比较成熟了,但是如果是把一个SPA应用改造成SSR应用,成本还是有些高的,这工作量无异于重构前端。另外对前端的技术要求也是挺高的,需要对Vue比较熟悉,还要有Node.js 和 webpack 的应用经验。

引入

Vue是一个构建客户端应用的框架,即vue组件是在浏览器中进行渲染的。所谓服务端渲染,指的是把vue组件在服务器端渲染为组装好的HTML字符串,然后将它们直接发送到浏览器,最后需要将这些静态标记"激活"为客户端上完全可交互的应用程序。

服务端渲染的优点

  1. 更好的SEO,搜索引擎爬虫可以抓取渲染好的页面
  2. 更快的内容到达时间(首屏加载更快),因为服务端只需要返回渲染好的HTML,这部分代码量很小的,所以用户体验更好

服务端渲染的缺点

  1. 首先就是开发成本比较高,比如某些声明周期钩子函数(如beforeCreate、created)能同时运行在服务端和客户端,因此第三方库要做特殊处理,才能在服务器渲染应用程序中运行。
  2. 由于服务端渲染要用Nodejs做中间层,所以部署项目时,需要处于Node.js server运行环境。在高流量环境下,还要做好服务器负载和缓存策略

原理解析

先附上demo地址:https://github.com/wmui/vue-s...

第一步:编写entry-client.js和entry-server.js

entry-client.js只在浏览器环境下执行,所以需要显示调用$mount方法,挂载DOM节点

import Vue from 'vue';
import App from './App.vue';
import createStore from './store/index.js';

function createApp() {
  const store = createStore();
  const app = new Vue({
      store,
      render: h => h(App)
  });
  return {app, store}
}

const { app, store } = createApp();

// 使用window.__INITIAL_STATE__中的数据替换整个state中的数据,这样服务端渲染结束后,客户端也可以自由操作state中的数据
if (window.__INITIAL_STATE__) {
  store.replaceState(window.__INITIAL_STATE__);
}

app.$mount('#app');

entry-server.js需要导出一个函数,在服务端渲染期间会被调用

import Vue from 'vue';
import App from './App.vue';
import createStore from './store/index.js';

export default function(context) {
  // context是上下文对象
  const store = createStore();
  let app = new Vue({
    store,
    render: h => h(App)
  });

  // 找到所有 asyncData 方法
  let components = App.components;
  let asyncDataArr = []; // promise集合
  for (let key in components) {
    if (!components.hasOwnProperty(key)) continue;
    let component = components[key];
    if (component.asyncData) {
      asyncDataArr.push(component.asyncData({store})) // 把store传给asyncData
    }
  }
  // 所有请求并行执行
  return Promise.all(asyncDataArr).then(() => {
    // context.state 赋值成什么,window.__INITIAL_STATE__ 就是什么
    // 这下你应该明白entry-client.js中window.__INITIAL_STATE__是哪来的了,它是在服务端渲染期间被添加进上下文的
    context.state = store.state;
    return app;
  });
};

上面的asyncData是干嘛用的?其实,这个函数是专门请求数据用的,你可能会问请求数据为什么不在beforeCreate或者created中完成,还要专门定义一个函数?虽然beforeCreatecreated在服务端也会被执行(其他周期函数只会在客户端执行),但是我们都知道请求是异步的,这就导致请求发出后,数据还没返回,渲染就已经结束了,所以无法把 Ajax 返回的数据也一并渲染出来。因此需要想个办法,等到所有数据都返回后再渲染组件

asyncData需要返回一个promise,这样就可以等到所有请求都完成后再渲染组件。下面是在foo组价中使用asyncData的示例,在这里完成数据的请求

export default {
  asyncData: function({store}) {
    return store.dispatch('GET_ARTICLE') // 返回promise
  },
  computed: {
    article() {
      return this.$store.state.article
    }
  }
}

第二步:配置webpack

webpack配置比较简单,但是也需要针对client和server端单独配置

webpack.client.conf.js显然是用来打包客户端应用的

module.exports = merge(base, {
  entry: {
    client: path.join(__dirname, '../entry-client.js')
  }
});

webpack.server.conf.js用来打包服务端应用,这里需要指定node环境

module.exports = merge(base, {
  target: 'node', // 指定是node环境
  entry: {
    server: path.join(__dirname, '../entry-server.js')
  },
  output: {
    filename: '[name].js', // server.js
    libraryTarget: 'commonjs2' // 必须按照 commonjs规范打包才能被服务器调用。
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: path.join(__dirname, '../index.ssr.html'),
      filename: 'index.ssr.html',
      files: {
        js: 'client.js'
      }, // client.js需要在html中引入
      excludeChunks: ['server'] // server.js只在服务端执行,所以不能打包到html中
    })
  ]
});

第三步:启动服务

打包完成后就可以启动服务了,在start.js中我们需要把server.js加载进来,然后通过renderToString方法把渲染好的html返回给浏览器

const bundle = fs.readFileSync(path.resolve(__dirname, 'dist/server.js'), 'utf-8');
const renderer = require('vue-server-renderer').createBundleRenderer(bundle, {
  template: fs.readFileSync(path.resolve(__dirname, 'dist/index.ssr.html'), 'utf-8') // 服务端渲染数据
});


server.get('*', (req, res) => {
  renderer.renderToString((err, html) => {
    // console.log(html)
    if (err) {
      console.error(err);
      res.status(500).end('服务器内部错误');
      return;
    }
    res.end(html);
  })
});

效果图

demo已经上传到github: http://github.com/wmui/vue-ss...

clipboard.png

结语

个人实践Vue SSR已有一段时间,发现要想搭建一套完整的 SSR 服务框架还是很有挑战的,或许 Nuxt 是一个不错的选择,对 Nuxt 感兴趣的朋友可以参考我的一个开源小作品Essay

以上,感谢阅读!

查看原文

堂堂糖唐 回答了问题 · 2018-12-24

解决laravel Model 取数据 json 格式存储

看了已采纳答案,感觉不够简洁,再来个更精简的。

protected $casts = [
    'product_json' => 'array',
];

product_json字段可以是json或者string、text都行。

不过不知道5.5以前的版本行不行。

关注 4 回答 2

堂堂糖唐 发布了文章 · 2018-06-11

[Doctrine Migrations] 数据库迁移组件的深入解析三:自定义数据字段类型

自定义type

根据官方文档,新建TinyIntType类,集成Type,并重写getNamegetSqlDeclarationconvertToPHPValuegetBindingType等方法。

TinyIntType.php完整代码:

<?php
namespace db\types;
use Doctrine\DBAL\ParameterType;
use Doctrine\DBAL\Platforms\AbstractPlatform;
use Doctrine\DBAL\Types\Type;
/**
 * 扩展DBAL组件类型
 *
 * 迁移组件依赖的DBAL组件默认并不支持tinyint类型
 * 此类是为mysql支持tinyint类型而扩展的类
 *
 * @author tangbo<admin@tbphp.net>
 */
class TinyIntType extends Type
{
    public function getName()
    {
        return 'tinyint';
    }
    public function getSQLDeclaration(array $fieldDeclaration, AbstractPlatform $platform)
    {
        $sql = 'TINYINT';
        if (is_numeric($fieldDeclaration['length']) && $fieldDeclaration['length'] > 1) {
            $sql .= '(' . ((int) $fieldDeclaration['length']) . ')';
        } else {
            $sql .= '(3)';
        }
        if (!empty($fieldDeclaration['unsigned'])) {
            $sql .= ' UNSIGNED';
        }
        if (!empty($fieldDeclaration['autoincrement'])) {
            $sql .= ' AUTO_INCREMENT';
        }
        return $sql;
    }
    public function convertToPHPValue($value, AbstractPlatform $platform)
    {
        return (null === $value) ? null : (int) $value;
    }
    public function getBindingType()
    {
        return ParameterType::INTEGER;
    }
}

其中getSqlDeclaration方法是用于生成sql语句,需要根据传入的参数处理sql拼接。

注册自定义类型

Type::addType(TinyIntType::TYPENAME, 'db\types\TinyIntType');
$connection->getDatabasePlatform()->registerDoctrineTypeMapping(TinyIntType::TYPENAME, TinyIntType::TYPENAME);

这样,你在编写迁移类代码的时候就可以使用tinyint了,例如:

public function up(Schema $schema): void
{
    $table = $schema->createTable('test1');
    $table->addColumn('id', 'integer')->setUnsigned(true)->setAutoincrement(true);
    $table->addColumn('status', 'tinyint')->setLength(2)->setDefault(1);
    $table->setPrimaryKey(['id']);
}

解决enum类型冲突

迁移组件不支持enum类型,也无法自定义该类型。如果集成迁移组件的时候数据库里已经存在表且有enum类型的字段,那么执行迁移命令时就会报错。

为了解决这个问题,我们需要把enum映射为string类型即可:

$connection->getDatabasePlatform()->registerDoctrineTypeMapping('enum', 'string');

结语

至此,我们已经完成了迁移组件的所有迁移工作,并且已经能很好的在项目中使用它。

目前集成的是版本管理的方式,是迁移组件默认支持的,也是laravel框架集成的迁移方式。还有之前说到的另一种diff方式的迁移,diff方式能够更精准的控制表结构。

下一章我们来详细研究如何集成diff方式的数据迁移组件。

我的代码库可以查看这篇文章的详细代码,欢迎star。
查看原文

赞 1 收藏 1 评论 0

堂堂糖唐 发布了文章 · 2018-06-10

[Doctrine Migrations] 数据库迁移组件的深入解析二:自定义集成

自定义命令脚本

目录结构

目前的项目结构是这样的(参照代码库):

file

其中,db/migrations文件夹是迁移类文件夹,config/db.php是我们项目原有的db配置,migrations.phpmigrations-db.php是迁移组件需要的配置文件。

编写自定义命令脚本

现在先在根目录新建文件:migrate,没有后缀名,并且添加可执行权限。

并且参照组件原有的命令脚本vendor/doctrine/migrations/doctrine-migrations.php,首先获取项目原有的数据库配置信息,替换掉migrations-db.php数据库配置文件:

$db_config = include 'config/db.php';
$db_params = [
    'driver' => 'pdo_mysql',
    'host' => $db_config['host'],
    'port' => $db_config['port'],
    'dbname' => $db_config['dbname'],
    'user' => $db_config['user'],
    'password' => $db_config['password'],
];
try {
    $connection = DriverManager::getConnection($db_params);
} catch (DBALException $e) {
    echo $e->getMessage() . PHP_EOL;
    exit;
}

然后配置组件,替换掉migrations.php配置文件:

$configuration = new Configuration($connection);
$configuration->setName('Doctrine Migrations');
$configuration->setMigrationsNamespace('db\migrations');
$configuration->setMigrationsTableName('migration_versions');
$configuration->setMigrationsDirectory('db/migrations');

最后是完整的命令脚本代码:

#!/usr/bin/env php
<?php
require_once 'vendor/autoload.php';
use Doctrine\DBAL\DBALException;
use Doctrine\DBAL\DriverManager;
use Doctrine\DBAL\Migrations\Configuration\Configuration;
use Doctrine\DBAL\Migrations\Tools\Console\ConsoleRunner;
use Doctrine\DBAL\Migrations\Tools\Console\Helper\ConfigurationHelper;
use Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper;
use Symfony\Component\Console\Helper\HelperSet;
use Symfony\Component\Console\Helper\QuestionHelper;
// 读取数据库配置信息
$db_config = include 'config/db.php';
$db_params = [
    'driver' => 'pdo_mysql',
    'host' => $db_config['host'],
    'port' => $db_config['port'],
    'dbname' => $db_config['dbname'],
    'user' => $db_config['user'],
    'password' => $db_config['password'],
];
try {
    $connection = DriverManager::getConnection($db_params);
} catch (DBALException $e) {
    echo $e->getMessage() . PHP_EOL;
    exit;
}
// 迁移组件配置
$configuration = new Configuration($connection);
$configuration->setName('Doctrine Migrations');
$configuration->setMigrationsNamespace('db\migrations');
$configuration->setMigrationsTableName('migration_versions');
$configuration->setMigrationsDirectory('db/migrations');
// 创建命令脚本
$helper_set = new HelperSet([
    'question' => new QuestionHelper(),
    'db' => new ConnectionHelper($connection),
    new ConfigurationHelper($connection, $configuration),
]);
$cli = ConsoleRunner::createApplication($helper_set);
try {
    $cli->run();
} catch (Exception $e) {
    echo $e->getMessage() . PHP_EOL;
}

现在执行迁移相关命令时,用./migrate替换之前的vendor/bin/doctrine-migrations部分即可。

同时migrations.phpmigrations-db.php这两个配置文件也可以删除了。

PhpStorm集成迁移命令

如果你使用PhpStorm,命令行还可以集成到开发工具中去,会有自动提示,大大提高工作效率:

  1. PhpStorm -> Preferences -> Command Line Tool Support -> 添加
  2. Choose tool选择Tool based on Symfony Console,点击OK
  3. Alias输入m, Path to PHP executable 选择php路径,path to script选择跟目录下的migrate文件
  4. 点击OK,提示 Found 9 commands 则配置成功。
  5. PhpStorm -> Tools -> Run Command,弹出命令窗口,输入m即会出现命令提示。

结语

到此,数据迁移组件就已经很灵活的集成到我们自己的项目中了,而且你还可以根据自己的项目灵活修改自定义命令脚本文件。

但是如果使用久了会发现现在的数据迁移会有两个问题:

  1. 不支持tinyint类型,在相关issues中,官方开发人员有回复:

    "Tiny integer" is not supported by many database vendors. DBAL's type system is an abstraction layer for SQL types including type conversion from PHP to database value and back. I am assuming that your issue refers to MySQL, where we do not have a distinct native SQL type to use for BooleanType mapping. Therefore MySQL's TINYINT is used for that purpose as is fits best from all available native types and in DBAL we do not have an abstraction for tiny integers as such (as mentioned above).

    What you can do is implement your own tiny integer custom type and tell DBAL to use column comments (for distinction from BooleanType in MySQL). That should work. See the documentation.

    To tell DBAL to use column comments for the custom type, simply override the requiresSQLCommentHint() method to return true.
    所以只能添加自定义类型。

  2. 另外一个问题,就是不支持enum类型。深入代码之后,发现enum类型的特殊格式并不好融入到组件中去,自定义类型也不能支持,但是如果你是半途中加入数据迁移组件,现在项目中如果已经有了数据表结构,且包含enum类型的字段,那么使用迁移组件是会报错。

那么,下一章我们就来完成这两件事:添加tinyint的自定义类型,解决enum报错的问题。

我的代码库可以查看这篇文章的详细代码,欢迎star。
查看原文

赞 0 收藏 0 评论 0

堂堂糖唐 发布了文章 · 2018-06-10

[Doctrine Migrations]数据库迁移组件的深入解析一:安装与使用

场景分析

团队开发中,每个开发人员对于数据库都修改都必须手动记录,上线时需要人工整理,运维成本极高。而且在多个开发者之间数据结构同步也是很大的问题。Doctrine Migrations组件把数据库变更加入到代码中和代码一起进行版本管理,很好的解决了上述问题。

Doctrine Migrations是基于Doctrine DBAL组件的数据迁移组件。集成于Laravel,Symfony等主流框架。大概可以分为两种方式进行迁移,即版本管理方式和diff方式。

版本管理:把数据库变更写入到代码中,来进行版本管理。Laravel框架就是版本管理的模式,迁移组件默认的命令行就是支持这种模式。

diff:把现有数据库结构和代码里面的数据库结构来做对比,执行差异的sql以保证一致性。一般需要ORM的支持,Symfony框架就是使用Doctrine2ORM工具加上Doctrine DBAL来进行diff方式的数据迁移。

此系列文章不讨论现有框架中数据迁移组件的使用,而是着重于探讨如何单独使用迁移组件以及如何把数据迁移组件集成到自己的项目、个性化定制

安装

composer安装

composer require doctrine/migrations ~1.8.0
本系列使用的是目前最新的1.8.1版本

配置

安装之后不能直接使用,还需要进行组件配置以及数据库配置:

  1. 根目录下建立migrations.php文件,配置组件:

    return [
        'name' => 'Doctrine Migrations', // 组件显示名称
        'migrations_namespace' => 'db\migrations', // 迁移类的命名空间
        'table_name' => 'migration_versions', // 迁移组件的表名
        'migrations_directory' => 'db/migrations', // 迁移类的文件夹
    ];

    详情的配置参数参见官方文档

  2. 根目录下简历migrations-db.php文件,配置数据库信息:

    return [
        'driver' => 'pdo_mysql',
        'host' => 'localhost',
        'port' => 3306,
        'user' => 'root',
        'password' => '1236',
        'dbname' => 'migrations',
    ];

到此,组件需要的配置已经完成。

使用

  1. 运行vendor目录下面的命令生成版本迁移类文件。

    ./vendor/bin/doctrine-migrations migrations:generate

    在迁移类目录/db/migrations下面生成Version20180608155932.php类文件,此文件即是用于写入迁移sql的类,Version后面的数字则是当前版本号。

  2. 重写up方法,用于执行迁移sql:

    public function up(Schema $schema): void
    {
        $table = $schema->createTable('test1');
        $table->addColumn('id', 'integer')->setUnsigned(true)->setAutoincrement(true);
        $table->addColumn('name', 'string')->setDefault('')->setLength(20);
        $table->setPrimaryKey(['id']);
    }

    这个脚本是生成一个test1的表。

  3. 重写down方法,用于版本回退,撤销up方法的迁移操作:

    public function down(Schema $schema): void
    {
        if ($schema->hasTable('test1')) {
            $schema->dropTable('test1');
        }
    }
  4. 执行迁移命令:

    ./vendor/bin/doctrine-migrations migrations:migrate

这样就成功的创建了一个版本的迁移数据。迁移类脚本可以使用$schema来操作数据库实体,也可以使用$this->addSql()方法来直接写入相关的sql,详细参加官方文档对于脚本编写的详细说明,此处不过多展开。

版本管理

既然迁移使用版本管理,那么多个版本之间可以来回切换。下面是相关的版本切换命令:

./vendor/bin/doctrine-migrations migrations:migrate 20180608161758

这条命令是恢复到20180608161758版本,除了直接输入具体版本号之外,还有更加方便的版本别名:

  • first:回退到初始版本
  • prev:回到上一个版本
  • next:迁移到下一个版本
  • latest:迁移到最新版本(和不加版本号效果一样)

常用命令

# 生成迁移脚本
php migration.php migrations:generate
# 执行迁移到最新版本
php migration.php migrations:migrate
# --dry-run是空转参数,只显示操作结果,不执行修改
php migration.php migrations:migrate --dry-run
# 不执行操作,只写入文件,对于生产环境需要手动验证并执行的场景有用
php migration.php migrations:migrate --write-sql=file.sql
# 查看详细信息
php migration.php status

结语

到此,就学会了migrations组件的基本使用,但是还有如下几个问题需要我们解决:

  1. 一般项目中都会有数据库配置文件,如何让组件公用项目中的配置文件?
  2. 现在迁移组件所需要的配置文件只能在根目录,如何让配置文件更合理的归档?
  3. 命令行又长又难记,如何简单使用命令行?

下一章,我们会解决以上问题,并且让组件更个性化的融入到我们自己的项目中去。

我的代码库可以查看这篇文章的详细代码。
查看原文

赞 0 收藏 0 评论 0

堂堂糖唐 发布了文章 · 2018-06-09

[Doctrine Migrations]数据库迁移组件的深入解析一:安装与使用

场景分析

团队开发中,每个开发人员对于数据库都修改都必须手动记录,上线时需要人工整理,运维成本极高。而且在多个开发者之间数据结构同步也是很大的问题。Doctrine Migrations组件把数据库变更加入到代码中和代码一起进行版本管理,很好的解决了上述问题。

Doctrine Migrations是基于Doctrine DBAL组件的数据迁移组件。集成于Laravel,Symfony等主流框架。大概可以分为两种方式进行迁移,即版本管理方式和diff方式。

版本管理:把数据库变更写入到代码中,来进行版本管理。Laravel框架就是版本管理的模式,迁移组件默认的命令行就是支持这种模式。

diff:把现有数据库结构和代码里面的数据库结构来做对比,执行差异的sql以保证一致性。一般需要ORM的支持,Symfony框架就是使用Doctrine2ORM工具加上Doctrine DBAL来进行diff方式的数据迁移。

此系列文章不讨论现有框架中数据迁移组件的使用,而是着重于探讨如何单独使用迁移组件以及如何把数据迁移组件集成到自己的项目、个性化定制

安装

composer安装

composer require doctrine/migrations ~1.8.0
本系列使用的是目前最新的1.8.1版本

配置

安装之后不能直接使用,还需要进行组件配置以及数据库配置:

  1. 根目录下建立migrations.php文件,配置组件:

    return [
        'name' => 'Doctrine Migrations', // 组件显示名称
        'migrations_namespace' => 'db\migrations', // 迁移类的命名空间
        'table_name' => 'migration_versions', // 迁移组件的表名
        'migrations_directory' => 'db/migrations', // 迁移类的文件夹
    ];

    详情的配置参数参见官方文档

  2. 根目录下简历migrations-db.php文件,配置数据库信息:

    return [
        'driver' => 'pdo_mysql',
        'host' => 'localhost',
        'port' => 3306,
        'user' => 'root',
        'password' => '1236',
        'dbname' => 'migrations',
    ];

到此,组件需要的配置已经完成。

使用

  1. 运行vendor目录下面的命令生成版本迁移类文件。

    ./vendor/bin/doctrine-migrations migrations:generate

    在迁移类目录/db/migrations下面生成Version20180608155932.php类文件,此文件即是用于写入迁移sql的类,Version后面的数字则是当前版本号。

  2. 重写up方法,用于执行迁移sql:

    public function up(Schema $schema): void
    {
        $table = $schema->createTable('test1');
        $table->addColumn('id', 'integer')->setUnsigned(true)->setAutoincrement(true);
        $table->addColumn('name', 'string')->setDefault('')->setLength(20);
        $table->setPrimaryKey(['id']);
    }

    这个脚本是生成一个test1的表。

  3. 重写down方法,用于版本回退,撤销up方法的迁移操作:

    public function down(Schema $schema): void
    {
        if ($schema->hasTable('test1')) {
            $schema->dropTable('test1');
        }
    }
  4. 执行迁移命令:

    ./vendor/bin/doctrine-migrations migrations:migrate

这样就成功的创建了一个版本的迁移数据。迁移类脚本可以使用$schema来操作数据库实体,也可以使用$this->addSql()方法来直接写入相关的sql,详细参加官方文档对于脚本编写的详细说明,此处不过多展开。

版本管理

既然迁移使用版本管理,那么多个版本之间可以来回切换。下面是相关的版本切换命令:

./vendor/bin/doctrine-migrations migrations:migrate 20180608161758

这条命令是恢复到20180608161758版本,除了直接输入具体版本号之外,还有更加方便的版本别名:

  • first:回退到初始版本
  • prev:回到上一个版本
  • next:迁移到下一个版本
  • latest:迁移到最新版本(和不加版本号效果一样)

常用命令

# 生成迁移脚本
php migration.php migrations:generate
# 执行迁移到最新版本
php migration.php migrations:migrate
# --dry-run是空转参数,只显示操作结果,不执行修改
php migration.php migrations:migrate --dry-run
# 不执行操作,只写入文件,对于生产环境需要手动验证并执行的场景有用
php migration.php migrations:migrate --write-sql=file.sql
# 查看详细信息
php migration.php status

结语

到此,就学会了migrations组件的基本使用,但是还有如下几个问题需要我们解决:

  1. 一般项目中都会有数据库配置文件,如何让组件公用项目中的配置文件?
  2. 现在迁移组件所需要的配置文件只能在根目录,如何让配置文件更合理的归档?
  3. 命令行又长又难记,如何简单使用命令行?

下一章,我们会解决以上问题,并且让组件更个性化的融入到我们自己的项目中去。

我的代码库可以查看这篇文章的详细代码。
查看原文

赞 0 收藏 0 评论 0

堂堂糖唐 赞了文章 · 2018-04-05

教你在不使用框架的情况下也能写出现代化 PHP 代码

file

我为你们准备了一个富有挑战性的事情。接下来你们将以 框架的方式开启一个项目之旅。

首先声明, 这篇并非又臭又长的反框架裹脚布文章。也不是推销 非原创 思想 。毕竟, 我们还将在接下来的开发之旅中使用其他框架开发者编写的辅助包。我对这个领域的创新也是持无可非议的态度。

这无关他人,而是关乎己身。作为一名开发者,它将有机会让你成长。

也许无框架开发令你受益匪浅的地方就是,可以从底层运作的层面中汲取丰富的知识。抛却依赖神奇的,帮你处理无法调试和无法真正理解的东西的框架,你将清楚的看到这一切是如何发生的。

很有可能下一份工作中,你并不能随心所以地选择框架开拓新项目。现实就是,在很多高价值,关键业务的 PHP 工作中均使用现有应用。 并且该应用程序是否构建在当前令人舒爽的 Laravel 或 Symfony 等流行框架中,亦或是陈旧过时的 CodeIgniter 或者 FuelPHP 中,更有甚者它可能广泛出现在令人沮丧的  “面向包含体系结构” 的传统的 PHP 应用 之中,所以框架开发会在将来你所面临的任何 PHP 项目中助你一臂之力。

上古时代, 因为 某些系统 不得不解释分发 HTTP 请求,发送 HTTP 响应,管理依赖关系,无框架开发就是痛苦的鏖战。缺乏行业标准必然意味着,框架中的这些组件高度耦合 。如果你从无框架开始,你终将难逃自建框架的命运。

时至今日,幸亏有 PHP-FIG 完成所有的自动加载和交互工作,无框架开发并非让你白手起家。各色供应商都有这么多优秀的可交互的软件包。把他们组合起来容易得超乎你的想象!

PHP 是如何工作的?

在做其他事之前,搞清楚 PHP 如何与外界沟通是非常重要的。

PHP 以请求 / 响应为周期运行服务端应用程序。与你的应用程序的每一次交互——无论是来自浏览器,命令行还是 REST API ——都是作为请求进入应用程序的。 当接收到请求以后:

  1. 程序开始启动;
  2. 开始处理请求;
  3. 产生响应;
  4. 接着,响应返回给产生请求的相应客户端;
  5. 最后程序关闭。

每一个 请求都在重复以上的交互。

前端控制器

用这些知识把自己武装起来以后,就可以先从我们的前端控制器开始编写程序了。前端控制器是一个 PHP 文件,它处理程序的每一个请求。控制器是请求进入程序后遇到的第一个 PHP 文件,并且(本质上)也是响应走出你应用程序所经过的最后一个文件。

我们使用经典的 Hello, world! 作为例子来确保所有东西都正确连接上,这个例子由 PHP 的内置服务器  驱动。在你开始这样做之前,请确保你已经安装了 PHP7.1 或者更高版本。

创建一个含有 public 目录的项目,然后在该目录里面创建一个index.php 文件,文件里面写入如下代码:

<?php
declare(strict_types=1);

echo 'Hello, world!';

注意,这里我们声明了使用严格模式 —— 作为最佳实践,你应该在应用程序的 每个 PHP 文件的开头 都这样做。因为对从你后面来的开发者来说类型提示对 调试和清晰的交流意图很重要 。

使用命令行(比如 macOS 的终端)切换到你的项目目录并启动 PHP 的内置服务器。

php -S localhost:8080 -t public/

现在,在浏览器中打开 http://localhost:8080/ 。是不是成功地看到了 "Hello, world!" 输出?

很好。接下来我们可以开始进入正题了!

自动加载与第三方包

当你第一次使用 PHP 时,你可能会在你的程序中使用 includes 或 requires 语句来从其他 PHP 文件导入功能和配置。 通常,我们会避免这么干,因为这会使得其他人更难以遵循你的代码路径和理解依赖在哪里。这让调试成为了一个 真正的 噩梦。

解决办法是使用自动加载(autoloading)。 自动加载的意思是:当你的程序需要使用一个类, PHP 在调用该类的时候知道去哪里找到并加载它。虽然从 PHP 5 开始就可以使用这个特性了, 但是得益于 PSR-0 ( 自动加载标准,后来被 PSR-4 取代),其使用率才开始有真正的提升。

我们可以编写自己的自动加载器来完成任务,但是由于我们将要使用的管理第三方依赖的  Composer 已经包含了一个完美的可用的自动加载器,那我们用它就行了。

确保你已经在你的系统上 安装 了 Composer。然后为此项目初始化 Composer:

composer init

这条命令通过交互式引导你创建 composer.json 配置文件。 一旦文件创建好了,我们就可以在编辑器中打开它然后向里面写入 autoload 字段,使他看起来像这个样子(这确保了自动加载器知道从哪里找到我们项目中的类):

{
    "name": "kevinsmith/no-framework",
    "description": "An example of a modern PHP application bootstrapped without a framework.",
    "type": "project",
    "require": {},
    "autoload": {
        "psr-4": {
            "ExampleApp\\": "src/"
        }
    }
}

现在为此项目安装 composer,它引入了依赖(如果有的话),并为我们创建好了自动加载器:

composer install

更新 public/index.php 文件来引入自动加载器。在理想情况下,这将是你在程序当中使用的少数『包含』语句之一。

<?php
declare(strict_types=1);

require_once dirname(__DIR__) . '/vendor/autoload.php';

echo 'Hello, world!';

此时如果你刷新浏览器,你将不会看到任何变化。因为自动加载器没有修改或者输出任何数据,所以我们看到的是同样的内容。让我们把 Hello, world! 这个例子移动到一个已经自动加载的类里面看看它是如何运作的。

在项目根目录创建一个名为 src 的目录,然后在里面添加一个叫 HelloWorld.php 的文件,写入如下代码:

<?php
declare(strict_types=1);

namespace ExampleApp;

class HelloWorld
{
    public function announce(): void
    {
        echo 'Hello, autoloaded world!';
    }
}

现在到 public/index.php 里面用  HelloWorld 类的 announce 方法替换掉 echo 语句。

// ...

require_once dirname(__DIR__) . '/vendor/autoload.php';

$helloWorld = new \ExampleApp\HelloWorld();
$helloWorld->announce();

刷新浏览器查看新的信息!

什么是依赖注入?

依赖注入是一种编程技术,每个依赖项都供给它需要的对象,而不是在对象外获得所需的信息或功能。

举个例子,假设应用中的类方法需要从数据库中读取。为此,你需要一个数据库连接。常用的技术就是创建一个全局可见的新连接。

class AwesomeClass
{
    public function doSomethingAwesome()
    {
        $dbConnection = return new \PDO(
            "{$_ENV['type']}:host={$_ENV['host']};dbname={$_ENV['name']}",
            $_ENV['user'],
            $_ENV['pass']
        );

        // Make magic happen with $dbConnection
    }
}

但是这样做显得很乱,它把一个并非属于这里的职责置于此地---创建一个 数据库连接对象  检查凭证 , 还有 处理一些连接失败的问题---它会导致应用中出现 大量  重复代码。如果你尝试对这个类进行单元测试,会发现根本不可行。这个类和应用环境以及数据库高度耦合。

相反,为何不一开始就搞清楚你的类需要什么?我们只需要首先将 “PDO” 对象注入该类即可。

class AwesomeClass
{
    private $dbConnection;

    public function __construct(\PDO $dbConnection)
    {
        $this->dbConnection = $dbConnection;
    }

    public function doSomethingAwesome()
    {
        // Make magic happen with $this->dbConnection
    }
}

这样更简洁清晰易懂,且更不易产生 Bug。通过类型提示和依赖注入,该方法可以清楚准确地声明它要做的事情,而无需依赖外部调用去获取。在做单元测试的时候,我们可以很好地模拟数据库连接,并将其传入使用。

依赖注入容器 是一个工具,你可以围绕整个应用程序来处理创建和注入这些依赖关系。容器并不需要能够使用依赖注入技术,但随着应用程序的增长并变得更加复杂,它将大有裨益。

我们将使用 PHP 中最受欢迎的 DI 容器之一:名副其实的 PHP-DI(值得推荐的是它文档中的 依赖注入另解 可能会对读者有所帮助)

依赖注入容器

现在我们已经安装了 Composer ,那么安装 PHP-DI 就轻而易举了,我们继续回到命令行来搞定它。

composer require php-di/php-di

修改 public/index.php 用来配置和构建容器。

// ...

require_once dirname(__DIR__) . '/vendor/autoload.php';

$containerBuilder = new \DI\ContainerBuilder();
$containerBuilder->useAutowiring(false);
$containerBuilder->useAnnotations(false);
$containerBuilder->addDefinitions([
    \ExampleApp\HelloWorld::class => \DI\create(\ExampleApp\HelloWorld::class)
]);

$container = $containerBuilder->build();

$helloWorld = $container->get(\ExampleApp\HelloWorld::class);
$helloWorld->announce();

没啥大不了的。它仍是一个单文件的简单示例,你很容易能看清它是怎么运行的。

迄今为止, 我们只是在 配置容器 ,所以我们必须 显式地声明依赖关系 (而不是使用 自动装配 或 注解),并且从容器中检索 HelloWorld 对象。

小贴士:自动装配在你开始构建应用程序的时候是一个很不错的特性,但是它隐藏了依赖关系,难以维护。 很有可能在接下里的岁月里, 另一个开发者在不知情的状况下引入了一个新库,然后就造就了多个库实现一个单接口的局面,这将会破坏自动装配,导致一系列让接手者很容易忽视的的不可见的问题。

尽量 引入命名空间,可以增加代码的可读性。

<?php
declare(strict_types=1);

use DI\ContainerBuilder;
use ExampleApp\HelloWorld;
use function DI\create;

require_once dirname(__DIR__) . '/vendor/autoload.php';

$containerBuilder = new ContainerBuilder();
$containerBuilder->useAutowiring(false);
$containerBuilder->useAnnotations(false);
$containerBuilder->addDefinitions([
    HelloWorld::class => create(HelloWorld::class)
]);

$container = $containerBuilder->build();

$helloWorld = $container->get(HelloWorld::class);
$helloWorld->announce();

现在看来,我们好像是把以前已经做过的事情再拿出来小题大做。

毋需烦心,当我们添加其他工具来帮助我们引导请求时,容器就有用武之地了。它会在适当的时机下按需加载正确的类。

中间件

如果把你的应用想象成一个洋葱,请求从外部进入,到达洋葱中心,最后变成响应返回出去。那么中间件就是洋葱的每一层。它接收请求并且可以处理请求。要么把请求传递到更里层,要么向更外层返回一个响应(如果中间件正在检查请求不满足的特定条件,比如请求一个不存在的路由,则可能发生这种情况)。

如果请求通过了所有的层,那么程序就会开始处理它并把它转换为响应,中间件接收到响应的顺序与接收到请求的顺序相反,并且也能对响应做修改,然后再把它传递给下一个中间件。

下面是一些中间件用例的闪光点:

  • 在开发环境中调试问题
  • 在生产环境中优雅的处理异常
  • 对传入的请求进行频率限制
  • 对请求传入的不支持资源类型做出响应
  • 处理跨域资源共享(CORS)
  • 将请求路由到正确的处理类

那么中间件是实现这些功能的唯一方式吗?当然不是。但是中间件的实现使得你对请求 / 响应这个生命周期的理解更清晰。这也意味着你调试起来更简单,开发起来更快速。

我们将从上面列出的最后一条用例,也就是路由,当中获益。

路由

路由依靠传入的请求信息来确定应当由哪个类来处理它。(例如 URI  /products/purple-dress/medium 应该被  ProductDetails::class类接收处理,同时 purple-dress 和 medium 作为参数传入)

在范例应用中,我们将使用流行的 FastRoute 路由,基于 PSR-15兼容的中间件实现

中间件调度器

为了让我们的应用可以和 FastRoute 中间件---以及我们安装的其他中间件协同工作---我们需要一个中间件调度器。

PSR-15是为中间件和调度器定义接口的中间件标准(在规范中又称“请求处理器”),它允许各式各样的中间件和调度器互相交互。我们只需选择兼容 PSR-15 的调度器,这样就可以确保它能和任何兼容 PSR-15 的中间件协同工作。

我们先安装一个 Relay 作为调度器。

composer require relay/relay:2.x@dev

而且根据 PSR-15 的中间件标准要求实现可传递 兼容 PSR-7 的 HTTP 消息, 我们使用 Zend Diactoros 作为 PSR-7 的实现。

composer require zendframework/zend-diactoros

我们用 Relay 去接收中间件。

// ...

use DI\ContainerBuilder;
use ExampleApp\HelloWorld;
use Relay\Relay;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;

// ...

$container = $containerBuilder->build();

$middlewareQueue = [];

$requestHandler = new Relay($middlewareQueue);
$requestHandler->handle(ServerRequestFactory::fromGlobals());

我们在第 16 行使用 ServerRequestFactory::fromGlobals()  把 创建新请求的必要信息合并起来 然后把它传给 Relay。 这正是 Request 进入我们中间件堆栈的起点。

现在我们继续添加 FastRoute 和请求处理器中间件。 ( FastRoute 确定请求是否合法,究竟能否被应用程序处理,然后请求处理器发送 Request 到路由配置表中已注册过的相应处理程序中)

composer require middlewares/fast-route middlewares/request-handler

然后我们给 Hello, world! 处理类定义一个路由。我们在此使用 /hello 路由来展示基本 URI 之外的路由。

// ...

use DI\ContainerBuilder;
use ExampleApp\HelloWorld;
use FastRoute\RouteCollector;
use Middlewares\FastRoute;
use Middlewares\RequestHandler;
use Relay\Relay;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;
use function FastRoute\simpleDispatcher;

// ...

$container = $containerBuilder->build();

$routes = simpleDispatcher(function (RouteCollector $r) {
    $r->get('/hello', HelloWorld::class);
});

$middlewareQueue[] = new FastRoute($routes);
$middlewareQueue[] = new RequestHandler();

$requestHandler = new Relay($middlewareQueue);
$requestHandler->handle(ServerRequestFactory::fromGlobals());

为了能运行,你还需要修改 HelloWorld 使其成为一个可调用的类, 也就是说 这里类可以像函数一样被随意调用.

// ...

class HelloWorld
{
    public function __invoke(): void
    {
        echo 'Hello, autoloaded world!';
        exit;
    }
}

(注意在魔术方法 __invoke() 中加入exit;。 我们只需1秒钟就能搞定--只是不想让你遗漏这个事)

现在打开 http://localhost:8080/hello ,开香槟吧!

万能胶水

睿智的读者可能很快看出,虽然我们仍旧囿于配置和构建 DI 容器的藩篱之中,容器现在实际上对我们毫无用处。调度器和中间件在没有它的情况下也一样运作。

那它何时才能发挥威力?

嗯,如果---在实际应用程序中总是如此---HelloWorld类具有依赖关系呢?

我们来讲解一个简单的依赖关系,看看究竟发生了什么。

// ...

class HelloWorld
{
    private $foo;

    public function __construct(string $foo)
    {
        $this->foo = $foo;
    }

    public function __invoke(): void
    {
        echo "Hello, {$this->foo} world!";
        exit;
    }
}

刷新浏览器..

WOW!

看下这个 ArgumentCountError.

发生这种情况是因为 HelloWorld 类在构造的时候需要注入一个字符串才能运行,在此之前它只能等着。  正是容器要帮你解决的痛点。
我们在容器中定义该依赖关系,然后将容器传给 RequestHandler 去 解决这个问题.

// ...

use Zend\Diactoros\ServerRequestFactory;
use function DI\create;
use function DI\get;
use function FastRoute\simpleDispatcher;

// ...

$containerBuilder->addDefinitions([
    HelloWorld::class => create(HelloWorld::class)
        ->constructor(get('Foo')),
    'Foo' => 'bar'
]);

$container = $containerBuilder->build();

// ...

$middlewareQueue[] = new FastRoute($routes);
$middlewareQueue[] = new RequestHandler($container);

$requestHandler = new Relay($middlewareQueue);
$requestHandler->handle(ServerRequestFactory::fromGlobals());

嗟夫!当刷新浏览器的时候, "Hello, bar world!"将映入你的眼帘!

正确地发送响应

是否还记得我之前提到过的位于 HelloWorld 类中的 exit 语句?

当我们构建代码时,它可以让我们简单粗暴的获得响应,但是它绝非输出到浏览器的最佳选择。这种粗暴的做法给 HelloWorld 附加了额外的响应工作---其实应该由其他类负责的---它会过于复杂的发送正确的头部信息和 状态码,然后立刻退出了应用,使得 HelloWorld 之后 的中间件也无机会运行了。

记住,每个中间件都有机会在 Request 进入我们应用时修改它,然后 (以相反的顺序) 在响应输出时修改响应。 除了 Request 的通用接口, PSR-7 同样也定义了另外一种 HTTP 消息结构,以辅助我们在应用运行周期的后半部分之用:Response。(如果你想真正了解这些细节,请阅读 HTTP 消息以及什么让 PSR-7 请求和响应标准如此之好。)

修改 HelloWorld 返回一个 Response

// ...

namespace ExampleApp;

use Psr\Http\Message\ResponseInterface;

class HelloWorld
{
    private $foo;

    private $response;

    public function __construct(
        string $foo,
        ResponseInterface $response
    ) {
        $this->foo = $foo;
        $this->response = $response;
    }

    public function __invoke(): ResponseInterface
    {
        $response = $this->response->withHeader('Content-Type', 'text/html');
        $response->getBody()
            ->write("<html><head></head><body>Hello, {$this->foo} world!</body></html>");

        return $response;
    }
}

然后修改容器给 HelloWorld 提供一个新的 Response 对象。

// ...

use Middlewares\RequestHandler;
use Relay\Relay;
use Zend\Diactoros\Response;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;

// ...

$containerBuilder->addDefinitions([
    HelloWorld::class => create(HelloWorld::class)
        ->constructor(get('Foo'), get('Response')),
    'Foo' => 'bar',
    'Response' => function() {
        return new Response();
    },
]);

$container = $containerBuilder->build();

// ...

如果你现在刷新页面,会发现一片空白。我们的应用正在从中间件调度器返回正确的 Response 对象,但是... 肿么回事?

它啥都没干,就这样。

我们还需要一件东西来包装下:发射器。发射器位于应用程序和 Web 服务器(Apache,nginx等)之间,将响应发送给发起请求的客户端。它实际上拿到了 Response 对象并将其转化为 服务端 API 可理解的信息。

好消息! 我们已经用来封装请求的 Zend Diactoros 包同样也内置了发送 PSR-7 响应的发射器。

值得注意的是,为了举例,我们只是对发射器的使用小试牛刀。虽然它们可能会更复杂点,真正的应用应该配置成自动化的流式发射器用来应对大量下载的情况, Zend 博客展示了如何实现它

修改 public/index.php ,用来从调度器那里接收 Response ,然后传给发射器。

// ...

use Relay\Relay;
use Zend\Diactoros\Response;
use Zend\Diactoros\Response\SapiEmitter;
use Zend\Diactoros\ServerRequestFactory;
use function DI\create;

// ...

$requestHandler = new Relay($middlewareQueue);
$response = $requestHandler->handle(ServerRequestFactory::fromGlobals());

$emitter = new SapiEmitter();
return $emitter->emit($response);

刷新浏览器,业务恢复了!这次我们用了一种更健壮的方式来处理响应。

以上代码的第 15 行是我们应用中请求/响应周期结束的地方,同时也是 web 服务器接管的地方。

总结

现在你已经获得了现代化的 PHP 代码。 仅仅 44 行代码,在几个被广泛使用,经过全面测试和拥有可靠互操作性的组件的帮助下,我们就完成了一个现代化 PHP 程序的引导。它兼容 PSR-4, PSR-7PSR-11 以及 PSR-15,这意味着你可以使用自己选择的其他任一供应商对这些标准的实现,来构建自己的 HTTP 消息, DI 容器,中间件,还有中间件调度器。

我们深入理解了我们决策背后使用的技术和原理,但我更希望你能明白,在没有框架的情况下,引导一个新的程序是多么简单的一件事。或许更重要的是,我希望在有必要的时候你能更好的把这些技术运用到已有的项目中去。

你可以在 这个例子的 GitHub 仓库 上免费 fork 和下载它。

如果你正在寻找更高质量的解耦软件包资源,我衷心推荐你看看 Aura, 了不起的软件包联盟, Symfony 组件, Zend Framework 组件Paragon 计划的聚焦安全的库, 还有这个 关于 PSR-15 中间件的清单.

如果你想把这个例子的代码用到生产环境中, 你可能需要把路由和 容器定义 分离到它们各自的文件里面,以便将来项目复杂度提升的时候更好维护。我也建议 实现 EmitterStack 来更好的处理文件下载以及其他的大量响应。

如果有任何问题,疑惑或者建议,请 给我留言

更多现代化 PHP 知识,请前往 Laravel / PHP 知识社区
查看原文

赞 89 收藏 171 评论 8

堂堂糖唐 关注了标签 · 2018-03-30

php

PHP,是英文超文本预处理语言 Hypertext Preprocessor 的缩写。PHP 是一种开源的通用计算机脚本语言,尤其适用于网络开发并可嵌入HTML 中使用。PHP 的语法借鉴吸收 C语言、Java 和 Perl 等流行计算机语言的特点,易于一般程序员学习。(目前是 Web 开发性价比最高的语言)

关注 84330

堂堂糖唐 关注了用户 · 2018-03-30

安小下同学 @saboran

正直、坦诚
谦卑、自律

关注 1766

认证与成就

  • 获得 5 次点赞
  • 获得 2 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 2 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2017-02-24
个人主页被 812 人浏览