laravel框架使用了统一入口
laravel框架使用了统一入口，入口文件：/public/index.php
make('Illuminate\Contracts\Http\Kernel');//运行Kernel类的handle方法，主要动作是运行middleware和启动URL相关的Contrller$response = $kernel->handle( $request = Illuminate\Http\Request::capture()
);//控制器返回结果之后的操作，暂时还没看，以后补上$response->send();$kernel->terminate($request, $response);自动加载文件
laravel的自动加载，其实也就是Composer的自动加载
我的理解是，Composer根据声明的依赖关系，从相关库的源下载代码文件，并根据依赖关系在 Composer 目录下生成供类自动加载的 PHP 脚本，使用的时候，项目开始处引入 “/vendor/autoload.php” 文件，就可以直接实例化这些第三方类库中的类了。那么，Composer 是如何实现类的自动加载的呢？接下来，我们从 laravel 的入口文件开始顺藤摸瓜往里跟进，来一睹 Composer 自动加载的奥妙。
代码清单/bootstrap/autoload.php
<?php
define('LARAVEL_START', microtime(true));//这就是传说中Composer的自动加载文件require __DIR__.'/../vendor/autoload.php';//Composer自动生成的各个核心类的集合，如果你需要修改一些vendor里面的文件来查看一些laravel运行细节，那么就请删除此文件$compiledPath = __DIR__.'/../vendor/compiled.php';if (file_exists($compiledPath))
{ require $compiledPath;
}代码清单 laravel/vendor/autoload.php
<?php// autoload.php @generated by Composerrequire_once __DIR__ . '/composer' . '/autoload_real.php';//别被吓到了,他就是autoload_real.php文件的类名而已return ComposerAutoloaderInit03dc6c3c47809c398817ca33ec5f6a01::getLoader();
代码清单laravel/vendor/composer/autoload_real.php：
主要是getLoader方法里面，加了注释的几行，这是关键
$path) { $loader->set($namespace, $path);
} //Psr4标准-设置命名空间对应的路径，以便于随后自动加载相关类文件（看看psr0和psr4的区别） $map = require __DIR__ . '/autoload_psr4.php'; foreach ($map as $namespace => $path) { $loader->setPsr4($namespace, $path);
} //设置类文件路径与类名的对应关系，以便于随后自动加载相关类文件（可能你有一部分类，由于历史原因，他们的命名空间不遵守PSR0和PSR4，你就可以使用此方法自动加载） $classMap = require __DIR__ . '/autoload_classmap.php'; if ($classMap) { $loader->addClassMap($classMap);
} //根据上述三种方法注册自动加载文档的方法，可以查看一下PHP的spl_autoload_register和__autoload方法 $loader->register(true); //加载公用方法，比如app()方法取得一个application实例，就是这里加载的，可以查看一下autoload_files.php文件都加载了什么公用方法，有很多关于 array的操作方法哦 $includeFiles = require __DIR__ . '/autoload_files.php'; foreach ($includeFiles as $file) {
composerRequire03dc6c3c47809c398817ca33ec5f6a01($file);
} return $loader;
}
}function composerRequire03dc6c3c47809c398817ca33ec5f6a01($file)
{ require $file;
}对于laravel自动加载过程的总结
laravel自动加载的过程就是这样实现的，总结为四种加载方式:
PSR0加载方式—对应的文件就是autoload_namespaces.php
PSR4加载方式—对应的文件就是autoload_psr4.php
其他加载类的方式—对应的文件就是autoload_classmap.php
加载公用方法—对应的文件就是autoload_files.php
怎么样自定义自动加载方式
如果某些文件，需要自动自定义加载方式，可以在Composer.json文件中定义
"autoload" : { //以第一种方式自动加载，表示app目录下的所有类的命名空间都是以Apppsr0开始且遵循psr0规范（注意：您的laravel中没有此项，作为示意例子） "psr-0" : { "AppPsr0": "apppsr0/"
}， //以第二种方式自动加载，表示app目录下的所有类的命名空间都是以App开始且遵循psr4规范 "psr-4" : { "App\\": "app/"
}， //以第三种加载方式自动加载，它会将所有.php和.inc文件中的类提出出来然后以类名作为key，类的路径作为值 "classmap" : ["database"], //以第四种加载方式自动加载,composer会把这些文件都include进来（注意：您的laravel中没有此项，作为示意例子） "files" : ["common/util.php"]
}服务容器——laravel真正的核心
服务容器，也叫IOC容器，其实包含了依赖注入(DI)和控制反转(IOC)两部分，是laravel的真正核心。其他的各种功能模块比如 Route（路由）、Eloquent ORM（数据库 ORM 组件）、Request and Response（请求和响应）等等等等，实际上都是与核心无关的类模块提供的，这些类从注册到实例化，最终被你所使用，其实都是 laravel 的服务容器负责的。服务容器这个概念比较难解释清楚，只能一步步从服务容器的产生历史慢慢解释
IoC 容器诞生的故事——石器时代（原始模式）
我们把一个“超人”作为一个类，
class Superman {}我们可以想象，一个超人诞生的时候肯定拥有至少一个超能力，这个超能力也可以抽象为一个对象，为这个对象定义一个描述他的类吧。一个超能力肯定有多种属性、（操作）方法，这个尽情的想象，但是目前我们先大致定义一个只有属性的“超能力”，至于能干啥，我们以后再丰富：
class Power { /**
* 能力值
*/ protected $ability; /**
* 能力范围或距离
*/ protected $range; public function __construct($ability, $range)
{ $this->ability = $ability; $this->range = $range;
}
}这时候我们回过头，修改一下之前的“超人”类，让一个“超人”创建的时候被赋予一个超能力：
class Superman
{ protected $power; public function __construct()
{ $this->power = new Power(999, 100);
}
}这样的话，当我们创建一个“超人”实例的时候，同时也创建了一个“超能力”的实例，但是，我们看到了一点，“超人”和“超能力”之间不可避免的产生了一个依赖。
所谓“依赖”，就是“我若依赖你，少了你就没有我”。
在一个贯彻面向对象编程的项目中，这样的依赖随处可见。少量的依赖并不会有太过直观的影响，我们随着这个例子逐渐铺开，让大家慢慢意识到，当依赖达到一个量级时，是怎样一番噩梦般的体验。当然，我也会自然而然的讲述如何解决问题。
之前的例子中，超能力类实例化后是一个具体的超能力，但是我们知道，超人的超能力是多元化的，每种超能力的方法、属性都有不小的差异，没法通过一种类描述完全。我们现在进行修改，我们假设超人可以有以下多种超能力：
飞行，属性有：飞行速度、持续飞行时间
蛮力，属性有：力量值
能量弹，属性有：伤害值、射击距离、同时射击个数
我们创建了如下类：
class Flight
{ protected $speed; protected $holdtime; public function __construct($speed, $holdtime) {}
}class Force
{ protected $force; public function __construct($force) {}
}class Shot
{ protected $atk; protected $range; protected $limit; public function __construct($atk, $range, $limit) {}
}好了，这下我们的超人有点“忙”了。在超人初始化的时候，我们会根据需要来实例化其拥有的超能力吗，大致如下：
class Superman
{ protected $power; public function __construct()
{ $this->power = new Fight(9, 100); // $this->power = new Force(45); // $this->power = new Shot(99, 50, 2); /*
$this->power = array(
new Force(45),
new Shot(99, 50, 2)
);
*/
}
}我们需要自己手动的在构造函数内（或者其他方法里）实例化一系列需要的类，这样并不好。可以想象，假如需求变更（不同的怪物横行地球），需要更多的有针对性的 新的 超能力，或者需要 变更 超能力的方法，我们必须 重新改造 超人。换句话说就是，改变超能力的同时，我还得重新制造个超人。效率太低了！新超人还没创造完成世界早已被毁灭。
这时，灵机一动的人想到：为什么不可以这样呢？超人的能力可以被随时更换，只需要添加或者更新一个芯片或者其他装置啥的（想到钢铁侠没）。这样的话就不要整个重新来过了。
IoC 容器诞生的故事——青铜时代（工厂模式）
我们不应该手动在 “超人” 类中固化了他的 “超能力” 初始化的行为，而转由外部负责，由外部创造超能力模组、装置或者芯片等（我们后面统一称为 “模组”），植入超人体内的某一个接口，这个接口是一个既定的，只要这个 “模组” 满足这个接口的装置都可以被超人所利用，可以提升、增加超人的某一种能力。这种由外部负责其依赖需求的行为，我们可以称其为 “控制反转（IoC）”。
工厂模式，顾名思义，就是一个类所以依赖的外部事物的实例，都可以被一个或多个 “工厂” 创建的这样一种开发模式，就是 “工厂模式”。
我们为了给超人制造超能力模组，我们创建了一个工厂，它可以制造各种各样的模组，且仅需要通过一个方法：
class SuperModuleFactory
{ public function makeModule($moduleName, $options)
{ switch ($moduleName) { case 'Fight': return new Fight($options[0], $options[1]); case 'Force': return new Force($options[0]); case 'Shot': return new Shot($options[0], $options[1], $options[2]);
}
}
}这时候，超人 创建之初就可以使用这个工厂！
class Superman
{ protected $power; public function __construct()
{ // 初始化工厂 $factory = new SuperModuleFactory; // 通过工厂提供的方法制造需要的模块 $this->power = $factory->makeModule('Fight', [9, 100]); // $this->power = $factory->makeModule('Force', [45]); // $this->power = $factory->makeModule('Shot', [99, 50, 2]); /*
$this->power = array(
$factory->makeModule('Force', [45]),
$factory->makeModule('Shot', [99, 50, 2])
);
*/
}
}可以看得出，我们不再需要在超人初始化之初，去初始化许多第三方类，只需初始化一个工厂类，即可满足需求。但这样似乎和以前区别不大，只是没有那么多 new 关键字。其实我们稍微改造一下这个类，你就明白，工厂类的真正意义和价值了。
class Superman
{ protected $power; public function __construct(array $modules)
{ // 初始化工厂 $factory = new SuperModuleFactory; // 通过工厂提供的方法制造需要的模块 foreach ($modules as $moduleName => $moduleOptions) { $this->power[] = $factory->makeModule($moduleName, $moduleOptions);
}
}
}// 创建超人$superman = new Superman([ 'Fight' => [9, 100],
'Shot' => [99, 50, 2]
]);现在修改的结果令人满意。现在，“超人” 的创建不再依赖任何一个 “超能力” 的类，我们如若修改了或者增加了新的超能力，只需要针对修改 SuperModuleFactory 即可。扩充超能力的同时不再需要重新编辑超人的类文件，使得我们变得很轻松。但是，这才刚刚开始。
IoC 容器诞生的故事——铁器时代（依赖注入）
由 “超人” 对 “超能力” 的依赖变成 “超人” 对 “超能力模组工厂” 的依赖后，对付小怪兽们变得更加得心应手。但这也正如你所看到的，依赖并未解除，只是由原来对多个外部的依赖变成了对一个 “工厂” 的依赖。假如工厂出了点麻烦，问题变得就很棘手。
其实大多数情况下，工厂模式已经足够了。工厂模式的缺点就是：接口未知（即没有一个很好的契约模型，关于这个我马上会有解释）、产生对象类型单一。总之就是，还是不够灵活。虽然如此，工厂模式依旧十分优秀，并且适用于绝大多数情况。不过我们为了讲解后面的 依赖注入 ，这里就先夸大一下工厂模式的缺陷咯。
我们知道，超人依赖的模组，我们要求有统一的接口，这样才能和超人身上的注入接口对接，最终起到提升超能力的效果。事实上，我之前说谎了，不仅仅只有一堆小怪兽，还有更多的大怪兽。嘿嘿。额，这时候似乎工厂的生产能力显得有些不足 —— 由于工厂模式下，所有的模组都已经在工厂类中安排好了，如果有新的、高级的模组加入，我们必须修改工厂类（好比增加新的生产线）：
class SuperModuleFactory
{ public function makeModule($moduleName, $options)
{ switch ($moduleName) { case 'Fight': return new Fight($options[0], $options[1]); case 'Force': return new Force($options[0]); case 'Shot': return new Shot($options[0], $options[1], $options[2]); // case 'more': ....... // case 'and more': ....... // case 'and more': ....... // case 'oh no! its too many!': .......
}
}
}看到没。。。噩梦般的感受！
其实灵感就差一步！你可能会想到更为灵活的办法！对，下一步就是我们今天的主要配角 —— DI （依赖注入）
<p style="margin: 10px auto; padding: 0px; list-style-type: none; list-style-image: none; color: rgb(68, 68, 68); font-family: Tahoma, Arial, Helvetica, sans-serif; font-size: 14px; white-space: normal; backgro
评论 (0)