Inspirer

推荐阅读

laravel 学习笔记 —— 数据和模型起步篇

来自于分类 笔记

自上一篇 《laravel 学习笔记 —— 神奇的服务容器》 已经有一年了,很多人都问过关于数据库部分的文章什么时候出来。其实不是不想写,而是没法写,因为当时大部分特性都没用到,以至于我无法以笔记形式给出。经过一年时间,laravel 已被我运用在很多类型的项目里,或多或少也对数据库组件了解的比较完整了,是时候完善学习笔记序列重要的环节之一 —— 数据库 部分。

Laravel 有三宝,路由、容器和 Eloquent ORM,Eloquent ORM 实际上是 Laravel 框架数据库组件的一个部分,也是最为重要和常用的,所以我们在说 Laravel 数据库组件时,往往指的是 Eloquent ORM。当然,数据库篇的文章肯定要全面讲述,这样有助于理解,也能帮助一些在这一块遇到问题的朋友。 数据库组件是一个比较独立的组件,其仅仅

【阅读全文】

最新文章

Laravel Pipeline 组件的实现

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

现在,Laravel 可以有更多可能。

我基于 Swoole 对 Laravel 框架的底层做了些许调整,使得其在能够运行至 Swoole 提供的强大特性下的同时,又能够不改变原有的开发模式(但是思路可能应该有些许调整了哦~)。现在已经有了一个可用的雏形,项目地址:

https://github.com/chongyi/swoole-laravel-framework

事实上已经有人做过此类工作,不过或多或少都有些不足,使得我们无法在一些工作中直接使用,例如对于文件上传和下载的支持不是很好,亦或者完全改动了原有的开发模式,使得旧的代码很难无缝切换。

当然,目前的情况依旧不允许直接使用在现有的项目中,因为还有很多未知 BUG 的存在。不过问题也在不断解决,毕竟本质上提供 HTTP 服务只要遵循 HTTP 协议就很难出现差池。

当前优先保证了 Laravel 5.1 下的可用,实际情况是 5.2 也能够得到支持,不过我会在基本功能稳定后建立 tag 便于各位后期能够快速通过 composer 安装。

欢迎各位 Star!也希望诸多大牛能够提供更多的建议~

计划基于 Laravel 实现开源的电商平台

我希望基于 Laravel 构建一个开源的电商平台,初始目标是能够令其适用于中小型的电子商务网站需求,同时也具备快速改造成内容管理系统或其他类型平台的能力。该项目将会对组件进行细分,在初期阶段作为整体开发,后期会将里面比较独立的部分拆出成为公共组件独立开发。

计划在明年 3 月完成所有后端模块,前端页面可能会因为时间和工作耽搁、存在不确定性而后发布。

这个计划更多是作为个人实验和学习使用,因此也希望愿意参与的朋友加入~共同进步~

项目地址:https://github.com/dybasedev/actloudbur

MIT License

说明:现在公司内部电商系统和作者思路相同,因此先暂时以公司内部项目为主,后期依旧会开源,且时间线同样在明年三月~~~

laravel 学习笔记 —— 查询构造器(上)

当下所有包含数据库组件的框架,都提供了一套流畅的操作方式去生成查询语句,这一部分我们称作 查询构造器 。查询构造器的存在,使得在数据库操作这一层面彻底的和原生开发区分开来。原生开发中,查询语句都是人为地根据业务需求手工写的,没有对查询语句进行规范的封装(即使有也不是人人能够做得到且做得好),随着项目扩展,这种原生的写法会导致项目愈发难以维护,而且由于操作原始,更加容易引发很多不必要的 BUG 以及安全隐患。查询构造器针对每一类语句关键字进行封装,通过流畅的链式方法组合,形成一个树状的数据结构,最终由生成器生成目标查询语句。

我向来认为 Laravel 框架的组件永远不是最优秀的,但由于其他框架或多或少不优雅、实现差、功能残缺,才使得 Laravel 的每个组件无论是单个拿出来看还是组合起来看,都是那么的好用,这其中的典型就是 查询构造器

laravel 学习笔记 —— 数据和模型之数据连接层

所谓万丈高楼平地起,再强大的功能组件,也是建立在许多功能很基础的模块之上。而且越是强大、富有扩展性,则拆分越细,分层越明显。Laravel 的许多组件都是这样,数据库组件当然更能直观体现出来这种设计思路。关于分层,我在上文已经给出了一定的解释,不再赘述。本文是对数据库的连接层进行讲述,在此,希望各位确保对 PDO 已经有了一定的认识和理解。

laravel 学习笔记 —— 数据和模型起步篇

自上一篇 《laravel 学习笔记 —— 神奇的服务容器》 已经有一年了,很多人都问过关于数据库部分的文章什么时候出来。其实不是不想写,而是没法写,因为当时大部分特性都没用到,以至于我无法以笔记形式给出。经过一年时间,laravel 已被我运用在很多类型的项目里,或多或少也对数据库组件了解的比较完整了,是时候完善学习笔记序列重要的环节之一 —— 数据库 部分。

Laravel 有三宝,路由、容器和 Eloquent ORM,Eloquent ORM 实际上是 Laravel 框架数据库组件的一个部分,也是最为重要和常用的,所以我们在说 Laravel 数据库组件时,往往指的是 Eloquent ORM。当然,数据库篇的文章肯定要全面讲述,这样有助于理解,也能帮助一些在这一块遇到问题的朋友。

数据库组件是一个比较独立的组件,只依赖很少的东西,通过 composer 安装的话,可以在任意一个项目里使用该组件的全部功能,而不需要安装 laravel 框架。具体使用方法可到其 github 主页获取:https://github.com/illuminate/database

由于篇幅有限,且平时很忙,我将会将数据库部分文章拆成包括本篇在内的多篇文章,本文作为概览和文章预告,会对整个数据库组件的构成做一个大致的讲解。

请等待一个新面孔

潜心工作难免疏忽,毕竟没法全心全意去维护博客。

不过心还在,近日仔细构思了一下,正在进行一系列重构。更多人在这个博客上可能更为关注 laravel 的一些内容。但是只是会用 laravel,也永远只会停留在浅薄的认识,我希望借助这个小小的地方发表我作为 PHPer 更多的愿景。PHP 也许不是最好的语言,但是却是一个值得把玩的语言,因为借助这门语言,可以很容易以此为跳板,去开启更多地新世界的大门。

近日的工作,忙碌中出现了很多失误,反思总结后,才更加坚定了走得太快迟早会扯蛋的这一认识。于是应当做出一些改变,也正如无数人反应的样式问题。

不过还是要说一下,,黑色的样式是为了便于长期在深夜工作的我眼睛着想。。。不过考虑到大家一般在白天看,我还是会调整回来的。

哦对了,这只是一篇小记,没什么干货。:joy: :joy:,干货很快就有了,别急。

MySQL5.7 的编译安装

一直嫌弃 MySQL 的编译安装,原因很简单,依赖复杂、容易出错,总之就是麻烦。但这些天由于需要必须编译安装,被迫阅读相关文档,发现现在的 MySQL 安装变得十分简单和容易。

直接开始吧。

一切从必要依赖开始。

yum install -y gcc gcc-c++ ncurses-devel perl

本文中系统为 CentOS 7,不同系统的软件包管理器可能用法不同,但需求类似,请准备好 gcc gcc++ ncurses 及 perl 相关编译器或依赖库即可。

扩展 Laravel 默认 Session 中间件导致的 Session 写入失效问题

最近由于项目开发需要,手机客户端和网页端统一使用一套接口,为保证 会话(Session) 能够正常且在各类情况下兼容,我希望能够改变 SessionID 的获取方式。默认情况下,所有网站都是通过 HTTP 请求的 Header 头部中的 Cookie 实现的,通过 Cookie 中指定的 SessionID 来关联到服务端对应数据,从而实现会话功能。

但对于手机客户端,可能并不会支持原始的 Cookie,亦或者根据平台需要而屏蔽,因此开发中要求通过增加一个请求头 X-Session-Token 来标识 SessionID。在 Laravel 框架中,实现 Session 初始化、读取和启动,都是通过 Illuminate\Session\Middleware\StartSession 这个中间件实现的,该中间件有一个关键方法 getSession,这个方法就是获取 SessionId 从而告知 Session 组件以什么凭据恢复 Session 数据。

该中间件注册于 app/Http/Kernel.php 文件下。

我新建了一个类继承该中间件,同时替换了在 app/Http/Kernel.php 下的注册的地方,原来的 getSession 方法源码如下:

public function getSession(Request $request)
{
    $session = $this->manager->driver();
    $session->setId($request->cookies->get($session->getName()));
    return $session;
}

在新的中间件中,我修改为:

public function getSession(Request $request)
{
    $session = $this->manager->driver();
    // 判断是否是接口访问并根据实际情况选择 SessionID 的获取方式
    if ($request->headers->has('x-session-token')) {
        $sessionId = $request->headers->has('x-session-token');
    } else {
        $sessionId = $request->cookies->get($session->getName());
    }
    $session->setId($sessionId);
    return $session;
}

但是麻烦也随之而来。。。