自上一篇 《laravel 学习笔记 —— 神奇的服务容器》 已经有一年了，很多人都问过关于数据库部分的文章什么时候出来。其实不是不想写，而是没法写，因为当时大部分特性都没用到，以至于我无法以笔记形式给出。经过一年时间，laravel 已被我运用在很多类型的项目里，或多或少也对数据库组件了解的比较完整了，是时候完善学习笔记序列重要的环节之一 —— 数据库 部分。
Laravel 有三宝，路由、容器和 Eloquent ORM，Eloquent ORM 实际上是 Laravel 框架数据库组件的一个部分，也是最为重要和常用的，所以我们在说 Laravel 数据库组件时，往往指的是 Eloquent ORM。当然，数据库篇的文章肯定要全面讲述，这样有助于理解，也能帮助一些在这一块遇到问题的朋友。 数据库组件是一个比较独立的组件，其仅仅
【阅读全文】The software should define what directories it needs in /run (which replaced /var/run in Fedora 15) by placing a configuration file in /usr/lib/tmpfiles.d. During the boot process, systemd-tmpfiles populates /run based on that confguration.
其中解释了 /run 是挂载在临时文件的系统里的，即在系统启动后，添加在里面的数据、文件都是写入内存的，因此重启后自然不存在。
懒得去翻的，本文直接给出一个便于快速查阅的方案。
今天在 SegmentFault 看到了类似问题，查资料回答那个问题后，决定留个笔记。
我们在计算金额时，难免存在保留位数有限，计算结果需要取舍的情况。往往在电商、银行系统中，金额是以整数形式保存，单位为货币最小单位，例如分。但是在结算时额外的参数如折扣、利率、税率等存在着大量的浮点数，计算结果则需要转换为整数。
简单处理一般是四舍五入，但是这样存在很明显的问题，就是 “入” 的概率大于 “舍”，明显的，遇到 1、2、3、4 舍，遇到 5、6、7、8、9 入，粗看这种就可以发现问题。如果想要两边平衡，则 “四舍六入” 才是合理的，但是，5 怎么办？
来继续填坑（上个月没发，因此这个月至少两篇）。
上一篇 laravel 学习笔记 —— 查询构造器（下） 中我们正在开始分析查询构造器的
where方法，作为出场率最高的方法，其中相关的玩意儿足以帮助我们去理解整个组件大致的设计思路和实现细节。由于整体分析实在是太过麻烦（我其实就是懒），因此我们在上一篇的末尾提了三个问题，本文也将顺着这三个问题来进行解析，当然其余的思路类似的，就不在赘述，毕竟精力有限。上一篇提到的问题是：
- where 方法中多余的参数是干什么的
- 方法中的代码为什么要拆分（或者封装）的那么细 ？
- Expression 这个类是干嘛的 ？
我们就从多余的参数是做什么的开始吧。
Laravel 框架中有一个非常有趣的功能，就是 HTTP 中间件，我们在定义路由的时候，通过中间件对访问进行过滤。来自外部的请求首先经过全局中间件，若通过，则会继续穿过层层路由组所设置的中间件，在到达目的路由，当然，目的路由也可能定义了个中间件，通过后，该路由的处理对象（如控制器），得到的就是一个经过过滤的请求了。
本文当然不是讨论中间件如何使用，而是其实现的基础。Laravel 框架中有一个组件叫做 Illuminate\Pipeline，意味 “管道”，我们看看下面这个代码示例：
<?php
use Illuminate\Pipeline\Pipeline;
$pipe1 = function ($poster, Closure $next) {
$poster += 1;
echo "pipe1: $poster\n";
return $next($poster);
};
$pipe2 = function ($poster, Closure $next) {
if ($poster > 7) {
return $poster;
}
$poster += 3;
echo "pipe2: $poster\n";
return $next($poster);
};
$pipe3 = function ($poster, Closure $next) {
$result = $next($poster);
echo "pipe3: $result\n";
return $result * 2;
};
$pipe4 = function ($poster, Closure $next) {
$poster += 2;
echo "pipe4 : $poster\n";
return $next($poster);
};
$pipes = [$pipe1, $pipe2, $pipe3, $pipe4];
function dispatcher($poster, $pipes)
{
echo "result: " . (new Pipeline)->send($poster)->through($pipes)->then(function ($poster) {
echo "received: $poster\n";
return 3;
}) . "\n";
}
echo "==> action 1:\n";
dispatcher(5, $pipes);
echo "==> action 2:\n";
dispatcher(7, $pipes);上述代码执行结果如下：
==> action 1:
pipe1: 6
pipe2: 9
pipe4 : 11
received: 11
pipe3: 3
result: 6
==> action 2:
pipe1: 8
result: 8现在，Laravel 可以有更多可能。
我基于 Swoole 对 Laravel 框架的底层做了些许调整，使得其在能够运行至 Swoole 提供的强大特性下的同时，又能够不改变原有的开发模式（但是思路可能应该有些许调整了哦~）。现在已经有了一个可用的雏形，项目地址：
事实上已经有人做过此类工作，不过或多或少都有些不足，使得我们无法在一些工作中直接使用，例如对于文件上传和下载的支持不是很好，亦或者完全改动了原有的开发模式，使得旧的代码很难无缝切换。
当然，目前的情况依旧不允许直接使用在现有的项目中，因为还有很多未知 BUG 的存在。不过问题也在不断解决，毕竟本质上提供 HTTP 服务只要遵循 HTTP 协议就很难出现差池。
当前优先保证了 Laravel 5.1 下的可用，实际情况是 5.2 也能够得到支持，不过我会在基本功能稳定后建立 tag 便于各位后期能够快速通过 composer 安装。
欢迎各位 Star！也希望诸多大牛能够提供更多的建议~
我希望基于 Laravel 构建一个开源的电商平台，初始目标是能够令其适用于中小型的电子商务网站需求，同时也具备快速改造成内容管理系统或其他类型平台的能力。该项目将会对组件进行细分，在初期阶段作为整体开发，后期会将里面比较独立的部分拆出成为公共组件独立开发。
计划在明年 3 月完成所有后端模块，前端页面可能会因为时间和工作耽搁、存在不确定性而后发布。
这个计划更多是作为个人实验和学习使用，因此也希望愿意参与的朋友加入~共同进步~
项目地址：https://github.com/dybasedev/actloudbur
MIT License
说明：现在公司内部电商系统和作者思路相同，因此先暂时以公司内部项目为主，后期依旧会开源，且时间线同样在明年三月~~~
当下所有包含数据库组件的框架，都提供了一套流畅的操作方式去生成查询语句，这一部分我们称作
查询构造器。查询构造器的存在，使得在数据库操作这一层面彻底的和原生开发区分开来。原生开发中，查询语句都是人为地根据业务需求手工写的，没有对查询语句进行规范的封装（即使有也不是人人能够做得到且做得好），随着项目扩展，这种原生的写法会导致项目愈发难以维护，而且由于操作原始，更加容易引发很多不必要的 BUG 以及安全隐患。查询构造器针对每一类语句关键字进行封装，通过流畅的链式方法组合，形成一个树状的数据结构，最终由生成器生成目标查询语句。
我向来认为 Laravel 框架的组件永远不是最优秀的，但由于其他框架或多或少不优雅、实现差、功能残缺，才使得 Laravel 的每个组件无论是单个拿出来看还是组合起来看，都是那么的好用，这其中的典型就是 查询构造器。
所谓万丈高楼平地起，再强大的功能组件，也是建立在许多功能很基础的模块之上。而且越是强大、富有扩展性，则拆分越细，分层越明显。Laravel 的许多组件都是这样，数据库组件当然更能直观体现出来这种设计思路。关于分层，我在上文已经给出了一定的解释，不再赘述。本文是对数据库的连接层进行讲述，在此，希望各位确保对 PDO 已经有了一定的认识和理解。
自上一篇 《laravel 学习笔记 —— 神奇的服务容器》 已经有一年了，很多人都问过关于数据库部分的文章什么时候出来。其实不是不想写，而是没法写，因为当时大部分特性都没用到，以至于我无法以笔记形式给出。经过一年时间，laravel 已被我运用在很多类型的项目里，或多或少也对数据库组件了解的比较完整了，是时候完善学习笔记序列重要的环节之一 ——
数据库部分。
Laravel 有三宝，路由、容器和 Eloquent ORM，Eloquent ORM 实际上是 Laravel 框架数据库组件的一个部分，也是最为重要和常用的，所以我们在说 Laravel 数据库组件时，往往指的是 Eloquent ORM。当然，数据库篇的文章肯定要全面讲述，这样有助于理解，也能帮助一些在这一块遇到问题的朋友。
数据库组件是一个比较独立的组件，只依赖很少的东西，通过 composer 安装的话，可以在任意一个项目里使用该组件的全部功能，而不需要安装 laravel 框架。具体使用方法可到其 github 主页获取：https://github.com/illuminate/database
由于篇幅有限，且平时很忙，我将会将数据库部分文章拆成包括本篇在内的多篇文章，本文作为概览和文章预告，会对整个数据库组件的构成做一个大致的讲解。