声明：本文非博主原创，来自《Laravel 4 From Apprentice to Artisan》阅读的翻译理解。当然不是原创翻译，可以保证90%的原创性。另外，由于是理解翻译，难免有错误，欢迎指正。欢迎转载，转载请注明出处，谢谢！服务提供者启动指南Laravel服务提供者是将服务绑定到IoC容器的类。事实上，框架的核心是由许多这样的服务提供者驱动来管理容器中绑定的各种资源。基本上框架中的所有组件都是以这种方式注册的，使用提供者将资源注入容器。当前项目使用的provider列表可以在项目文件app/config/app.php中的providers数组中浏览。服务提供者必须包含至少一种方法：注册。类绑定到容器的逻辑是在register方法中实现的。当用户发起请求时，框架启动，执行配置文件中定义的服务提供者的注册方法。这是在Laravel执行生命周期的早期触发的，因此当您的启动文件（例如启动目录中的文件）被加载时，这些服务启动器已经可用。RegistervsStartup不要尝试在register方法中使用provider服务。它仅用于将对象绑定到容器。所有对绑定类的后续操作都应该在boot方法中完成。一些通过Composer安装的第三方类库是通过服务提供者注入的。该库的安装说明将明确允许您通过向providers数组方法添加配置来在配置文件中使用它们的服务。一旦注册了服务提供者，就可以在程序的各个地方使用它。类库服务提供者并非所有类库都需要服务提供者。事实上，没有类库需要它，服务提供者的角色通常用于启动组件并使其可供立即使用。他其实是一个工具，方便我们启动容器绑定的bootstrap代码库。延迟提供者并不是所有列在提供者配置数组中的服务都会在每次请求时被实例化。这实际上对性能是不利的，尤其是当它们已经被注册了，但是在项目中却没有使用时，这是一种浪费。例如，QueueServiceProvider服务仅在使用队列的请求中使用。为了只实例化请求中那些必要的服务，laravel生成了一个“服务器清单”并将其存储在app/storage/meta目录中。清单列出了应用程序可能需要使用的所有服务，同时也记录了容器需要绑定的类库的名称。当应用程序需要使用队列服务时，Laravel知道如何从清单中加载和实例化QueueServiceProvider。这种延迟加载服务的方法大大提高了整体性能。清单生成当向providers数组添加数据时，Laravel会在下一个请求时自动重新生成清单。如果有时间，还是要好好看看这个列表，对你调试懒加载服务很有帮助。Organizer如果你想使用Laravel构建一个高度可扩展的应用程序，那么学习和使用服务提供者作为组织工具来管理我们的代码是很有必要的。在IoC容器中注入大量类时，代码比较杂乱，放在app/start文件中操作。我们可以使用服务提供者来注册服务，而不是上面的方法。所有的“启动文件”都存放在app/start目录下。当请求到达应用程序时，根据请求的类型加载适当的“引导程序”文件。根据当前环境加载start.php后的启动文件。例如：artisan.php只在终端命令行模式下加载。下面的例子。我们的应用程序可能正在使用Pusher4向用户推送消息。为了解耦Pusher，需要创建一个EventPusherInterface接口和一个PusherEventPuser实现。当需求发生变化时，我们可以很方便地更改消息服务提供者。接口EventPusherInterface{publicfunctionpush($message,array$data=array());}classPusherEventPusherimplementsEventPusherInterface{publicfunction__construct(PusherSdk$pusher){$this->pusher=$pusher;}publicfunctionpush($message,array$data=array()){//通过PusherSDK推送消息...}}接下来，我们创建一个EventPuserServiceProvider：useIlluminateSupportServiceProvider;classEventPusherServiceProviderextendsServiceProvider{publicfunctionregister(){$this->app->singleton('PusherSdk',function(){returnnewPusherSdk('app-key','secret-key');}$this->app->singleton('EventPusherInterface','PusherEventPusher');}}like!我们对时间推送有一个清晰的抽象，同时我们也有一个很好的地方可以将服务注册绑定到容器上，我们只需要在app/config/app.php的provider数组中添加EventPusherServiceProvider，在接下来的应用中，任何controller和class都可以使用这个注入的service。需要单例吗？我们始终需要正确使用bind和singleton。记住，使用单例一个请求只有一次，否则使用绑定。注意：服务提供者的$app变量来自ServiceProvider类。它是IlluminateFoundationApplication的一个实例化对象，继承自Container类，所以可以像上面那样调用容器中的各种方法。如果喜欢App的外观方式，还可以：App::singleton('EventPusherInterface','PusherEventPusher');当然，服务提供者的功能不仅限于此，我们还可以注册云存储、数据库访问、自定义模板引擎如Twig等类型的服务。它只是您应用程序中的指南和管理工具，仅此而已。因此，请随意创建您自己的服务提供商。这不需要你发布代码包，它只是一个管理工具，方便应用加载各种项目需要的组件。启动服务当所有服务提供者都注册后，它们就变成“启动”状态。每个提供程序中的引导方法都会触发。我们通常会犯这样的错误，试图在register方法中调用其他服务。这个时候并不能保证所有的服务都已经加载完毕，很可能一时服务不可用，就会出现错误。因此，我们应该始终在引导方法中调用其他服务。register方法仅用于将服务注册到容器中。在启动方法中，你可以做任何事情：注册事件监听器、加载路由文件、注册过滤器，以及任何你能想到的事情。同样，将服务提供商用作组织工具。也许您想组织一些聆听活动？把它们放到boot方法中去实现是个好方法！或者，您也可以引入一个PHP“事件”或“路由”文件：publicfunctionboot(){require_once__DIR__.'/events.php';require_once__DIR__.'/routes.php';}现在我们已经了解了依赖注入和使用服务提供者来组织项目，我们为使用Laravel创建可维护、可测试的应用程序架构打下了坚实的基础。接下来，让我们继续深入了解Laravel本身是如何使用服务提供者的，以及框架在这个引擎下是如何工作的！不要让自己被这些盒子束缚。请记住，只有包可以使用服务提供者。把他当作我们组织服务的好工具。ServiceCore您应该已经注意到，应用程序配置文件中已经有很多服务。每一个都启动框架核心的不同部分。例如MigrationServiceProvider负责加载数据库迁移类库，加载Artisan命令；EventServiceProvider负责注册事件调度类。有些服务相对负责，但都负责启动框架核心的某一部分。预约这些服务。了解这些核心服务的最好方法是阅读源代码。如果你非常熟悉这些服务和容器注入的源码，那么Laravel的工作原理就会变得非常清晰。大多数服务都是懒加载的，并不是所有的请求都会调用它们；但是，框架的基本部分，如FilesystemServiceProvider和ExceptionServiceProvider仍将随请求一起启动。有人会说CoreServicesandContainers_is_Laravel。Laravel就是将所有不同的部分组合成一个单一的、有凝聚力的整体。这些服务是构成建筑物的骨架。又啰嗦了，如果你想了解Laravel是如何工作的，你还是要看源码，看看框架是如何驱动这些核心服务的。能够理解这些服务是如何组织的，这些服务是如何实现自身功能的。了解了这些，说不定你也可以为Laravel做出自己的贡献！
