Author: admin

php 路由实现类,基于fastroute

<?php

/**
 * 核心路由查找器
 */

use FastRoute\RouteCollector;
use function FastRoute\simpleDispatcher;
use function FastRoute\cachedDispatcher;

class FastRoute {

 public function __construct()
 {
     
/** @var object $dispatcher 导入配置中的路由规则 */
// $dispatcher = simpleDispatcher(function (RouteCollector $r) {
    $dispatcher = cachedDispatcher(function (RouteCollector $r) {
        foreach 
    

Action-Domain-Responder

原文:https://herbertograca.com/2018/09/03/action-domain-responder/

这篇文章是软件架构编年史()的一部分,这部编年史由一系列关于软件架构的文章组成。在这一系列文章中,我将写下我对软件架构的学习和思考,以及我是如何运用这些知识的。如果你阅读了这个系列中之前的文章,本篇文章的的内容将更有意义。

MVC 诞生于 1979 年,它诞生于使用 CLI 用户界面的桌面应用上下文中,它暗示如果用户外部因素导致数据库变化,那么 UI 就应该自动地变化。同样的模式也可以完美地应用在稍后出现的 GUI 桌面应用上。

然而,它却和 Web 应用一直在磨合中,因为大多数 Web 应用不会用 UI 变化来作为服务端发生的变化的后果,它们总是从 UI 发起对服务端的调用来更新界面。

前面我已经介绍过 MVC 及其变种(),而这篇文章将介绍另一个变种:由 Paul M. Jones 提出的 Action-Domain-Responder

Laravel Model 利用 Macroable 为数据模型添加宏能力

【摘要】简单的说一下宏能力,这个类是 IlluminateSupportTraitsMacroable 其中利用重载实现了可以定义宏的功能,即通过 macro 静态方法添加回调,并定义一个名字。利用 __call 当前类没有这个函数的时候执行这个函数名注册的回调。

产生需求

在使用 Laravel 开发 ThinkSNS Plus 的时候,因为很多功能块都没有写在一个库里面,利用拓展包的形式添加实际功能,里面很多地方也用到了“多态多对多”的关系。问题来了,开发一个问答程序,想要给用户模型增加发布的问题或者回答的关系,起初是继承一份 User 模型,添加了关系,之后就发现问题了,因为用户的 tag 是使用多态多对多的关系,我通过继承的用户模型是无法拿到这种关系数据的因为 *able_type 是 user 数据模型类名称或者别名。而我继承之后类也就发生改变了。…

Laravel框架执行流程

俗话说知己知彼百战不怠,使用Laravel也有有一段时间了,中间也踩了很多坑,碰了很多壁,归根结底还是对Laravel的底层不太了解,以前使用Thinkphp养成的MVC的习惯,刚接触Laravel一时还没转变过来,所以最近抱着学习的态度,研究了下Laravel框架的执行流程。
Laravel虽然使用上感觉跟Thinkphp差不多,但是底层的实现方式还有框架的架构,跟Thinkphp差别还是蛮大,不过Tp5貌似吸收了很多Laravel中的特性。
废话到此为止,下面上干货

1. 入口文件index.php

1. 引入bootstrap/autoload.php,自动加载依赖库

2. 引入bootstrap/app.php’

  1. 创建容器$app
  1. // 参数为应用程序根目录
  2. $app = new Illuminate\Foundation\Application(
  3. realpath(__DIR__.'/../')
  4. );

 

  • 1
  • 1
  • 2
  • 3
  • 4
  1. 该类是框架核心类,负责启动框架,以及调动其他类提供的功能。
  2. 该类继承了Illuminate\Container\Container类,可见该类也是个容器。是整个框架最大的容器;
  3. 该类的构造器代码如下:
  1. public function __construct($basePath = null

Laravel 启动流程

使用 webpack 代码分割和魔术注释提升应用性能

1. Web 应用性能优化的关键

关于 Web 应用性能优化,有一点是毫无疑问的:「页面加载越久,用户体验就越差」。我们几乎可以说 Web 应用性能优化的关键之处就在于:减少页面初载时,所需加载资源的「数量」和「体积」。

那么当所需加载的资源数量到达多少或资源体积小于多少,我们才可以自信地宣称我们的 Web 应用拥有出色的性能呢?下面是给出的一些参考值,该参考值考虑到了移动端与国外等多种访问环境:

  • 页面初载时,所有未压缩的 JavaScript 脚本大小:<=200KB
  • 页面初载时,所有未压缩的 CSS 资源大小:<=100KB
  • HTTP 协议下,请求资源数:<=6 个
  • HTTP/2 协议下,请求资源数:<=20 个 ;
  • 90% 的代码利用率(也就是说,仅允许 10%
    

一文串联 HTTP / [0.9 | 1.0 | 1.1 | 2 | 3]

1989 年,万维网诞生之后,HTTP 迅速成为主导世界的应用层协议。在今天,几乎任何场景都或多或少用到了 HTTP 协议。

在 30 多年的历史中,HTTP 协议本身有比较大的发展,同时,还有一些重大的变动也在酝酿之中。这些演化使得这个协议的表现力更强,性能更好,更能满足日新月异的应用需求。本文就来回顾和展望一下 HTTP 的历史和未来。

  • HTTP/0.9
  • HTTP/1.0
  • HTTP/1.1
  • HTTP/2
  • HTTP/3

HTTP/0.9

HTTP/0.9 诞生于 1991 年,是 HTTP 协议的最初版,构造十分简单:

  • 请求端只支持 GET 请求
  • 响应端只能返回 HTML 文本数据
GET /index.html
<html>
  <body>
    Hello World
  </body>
</html>

请求示意图如下: