laravel门面与服务提供者区别

laravel门面模式与服务提供者区别

以 Laravel 自带的文件系统为例,在 config/app.php 的配置文件的 providers 数组中,注册了一个服务提供者:

Illuminate\Filesystem\FilesystemServiceProvider::class,
   

在 alias 数组中定义了一个门面:

‘File’ => Illuminate\Support\Facades\File::class,
   

通过这两个步骤,我们就可以非常方便的使用 Laravel 提供的文件系统相关的操作,而且调用形式很简洁,如:

File::exist ($path),判断文件是否存在。

File::get ($path, $lock = false),获取一个文件的内容。

File::append ($path, $data),把内容追加到一个文件末尾。

File::files ($directory),获取一个目录下所有文件。
   

那么这是如何做到的呢?下面分别讲一讲 Laravel 的服务提供者和门面模式。

服务提供者

先看看定义:

服务提供者是所有 Laravel 应用程序启动的中心所在。包括你自己的应用程序,以及所有的 Laravel 核心服务,都是通过服务提供者启动的。

在文件系统这个服务提供者中,位置/vendor/laravel/framework/src/Illuminate/Filesystem/FilesystemServiceProvider.php,register 方法可以看到绑定了一个单例:

protected function registerNativeFilesystem()

{

    $this->app->singleton(‘files‘, function () {

        return new Filesystem;

    });

}
   

这个单例是 Filesystem 这个类的单例模式。当然,这个服务提供者中也可以绑定其他的单例,或做更多的事情。我们这里只研究 File::exist () 这种调用方式的原理。

那么这样一来就有个 files 的单例,实际上是 Filesystem 这个类的实例。

此时,如果没有 Facade,也是可以调用到 Filesystem 这个实例的方法的,那就是这样调用:

app(‘files’)->exist($path)
   

好了,现在开始讲 Facade.

Facade 门面模式

先看下简介:

Facades /f??säd/ 为应用程序的服务容器中可用的类提供了一个「静态」接口。Laravel 自带了许多的 facades,可以用来访问其几乎所有的服务。Laravel facades 就是服务容器里那些基类的「静态代理」,相比于传统的静态方法调用,facades 在提供更简洁且丰富的语法的同时,还有更好的可测试性和扩展性。

本文一开始讲到 alias 数组定义了一个 File,具体的类是

Illuminate\Support\Facades\File::class,
   

它的内容是:

class File extends Facade

{

    /**

     * Get the registered name of the component.

     *

     * @return string

     */

    protected static function getFacadeAccessor()

    {

        return ‘files‘;

    }

}
   

它实际上返回了一个名称,注意这个名称 files,不就是刚刚绑定的单例模式的名称吗?没错。

这样一来,就可以使用 File 这个别名或者说门面,来调用这个 Filesystem 实例中的方法了。

通过本文,希望大家能够了解服务提供者,Facade,和实际调用的类的实例之间的关系。

原文地址:https://www.cnblogs.com/it-3327/p/11743564.html

时间: 2024-11-05 13:32:12

laravel门面与服务提供者区别的相关文章

laravel门面和服务提供者使用

关于laravel门面和服务提供者使用的一点见解,门面之词,不足之处,还请多多指教. 在laravel中,我们可能需要用到自己添加的类时,可以建立一个文件夹专门存放类文件,也可以使用laravel的服务提供者的方式来使用. 这两者其实区别不大,主要是前者使用的话,会跟业务代码产生依赖,想象一下,如果一个控制器之中引用了很多自定义的类文件的话,那么可以想像会产生多少依赖,所以我们可以使用服务提供者的方式,向laravel的容器内注册类,这样的话,就能够在一个单独的配置文件里面来管理依赖,逻辑和后期

laravel扩展包服务提供者的注册的两种方式

一. 包自动发现 在 Laravel 应用的配置文件 config/app.php 中,providers 配置项定义了一个会被 Laravel 加载的服务提供者列表.当安装完新的扩展包后,在老版本中需要将扩展包的服务提供者添加到这个列表以便被 Laravel 使用.从 Laravel 5.5 开始,我们不必再手动添加服务提供者到该列表,而是将提供者定义到扩展包下 composer.json 文件的 extra 选项中,除了服务提供者之外,我们还可以以这种方式注册门面: "extra"

laravel框架之服务提供者(提及契约Contracts)

首先理解两个概念 1.契约:一组定义了框架核心服务的接口 2.服务提供者:所有 Laravel 应用程序启动的中心所在. 包括你自己的应用程序,以及所有的 Laravel 核心服务,都是通过服务提供者启动的. 启动指的是 注册 事物,包括注册服务容器绑定.事件侦听器.中间件,甚至路由. 我们还是继续超人的故事,现在拿xpower来具体分析 xpower的诞生---(契约和服务提供者) 1.定义一个契约(接口) app\Contracts文件夹下 <?php namespace App\Contr

laravel框架容器管理的一些要点

本文面向php语言的laravel框架的用户,介绍一些laravel框架里面容器管理方面的使用要点.文章很长,但是内容应该很有用,希望有需要的朋友能看到.php经验有限,不到位的地方,欢迎帮忙指正. 1. laravel容器基本认识 laravel框架是有一个容器框架,框架应用程序的实例就是一个超大的容器,这个实例在bootstrap/app.php内进行初始化: 这个文件在每一次请求到达laravel框架都会执行,所创建的$app即是laravel框架的应用程序实例,它在整个请求生命周期都是唯

[php]laravel框架容器管理的一些要点

本文面向php语言的laravel框架的用户,介绍一些laravel框架里面容器管理方面的使用要点.文章很长,但是内容应该很有用,希望有需要的朋友能看到.php经验有限,不到位的地方,欢迎帮忙指正. 1. laravel容器基本认识 laravel框架是有一个容器框架,框架应用程序的实例就是一个超大的容器,这个实例在bootstrap/app.php内进行初始化: 这个文件在每一次请求到达laravel框架都会执行,所创建的$app即是laravel框架的应用程序实例,它在整个请求生命周期都是唯

laravel框架容器管理的一些要点(转)

本文面向php语言的laravel框架的用户,介绍一些laravel框架里面容器管理方面的使用要点.文章很长,但是内容应该很有用,希望有需要的朋友能看到.php经验有限,不到位的地方,欢迎帮忙指正. 1. laravel容器基本认识 laravel框架是有一个容器框架,框架应用程序的实例就是一个超大的容器,这个实例在bootstrap/app.php内进行初始化: 这个文件在每一次请求到达laravel框架都会执行,所创建的$app即是laravel框架的应用程序实例,它在整个请求生命周期都是唯

laravel5.2,注册服务提供者时无法生效

laravel中注册服务提供者原本很简单,只要运行下指令php artisan make:provider TestServiceProvider,然后在config/app.php的providers数组里注册下就可以. 但有时,你发现确实这样做了,但还是失效了!!!??? -------------------可爱的分割线——伟大的转折点这里开始----------------------------- 查看下bootstrap/cache目录下是否有config.php.OMG!真的有,那

laravel redis存数组并设置过期时间

$data = [ 'zoneList'=>$zoneList, 'eqList' => $eqList, 'mdateList' => $mdateList, 'workhoursList' => $workhoursList, 'pricerangeList' => $pricerangeList, ]; Redis::set($cacheKey, serialize($data)); Redis::expire($cacheKey, 300); laravel门面set

设计模式之中介者模式20170731

行为型设计模式之中介者模式: 一.含义 用一个中介对象封装一系列的对象交互,中介者使各对象不需要显示地相互作用,从而使其耦合松散,而且可以独立地改变它们之间的交互. 同事角色与其他同时角色通信的时候,一定要通过中介者角色(中介者封装了各个同事类之间的逻辑关系) 二.代码说明 1.主要有两个角色 1)中介者角色 通过协调各同事角色实现协作行为,因此它必须依赖于各个同事角色. 2)同事角色 每一个同事角色都知道中介者角色,而且与其他的同事角色通信的时候,一定要通过中介者角色协作. 每个同事类的行为分