laravel框架中服务容器的服务解析

当服务已经绑定到服务容器中后，就可以在之后的时间随时获取，也可以称为服务解析。服务解析需要两个步骤，一个是获取服务容器对象，在Laravel框架中因为所有的功能模块都是通过服务容器实例黏合在一起，所以大部分功能类中都记录服务容器实例的属性，通常为$app属性，也可以通过Facades中的App外观或app（）全局函数来获取；另一个是通过服务容器实现对应服务的解析。服务解析的几种实现代码如下：

上述四种方式都是通过服务名称来实现服务的解析，第一种方式是直接通过make（）方法实现的；第二种是通过类似访问数组的方式解析的，因为服务容器实现了ArrayAccess接口；第三种是通过全局函数app（）解析服务的，当传递参数为NULL时，则返回服务容器的实例，如果传递参数不为空，而是某个服务名称时，则会返回相应的服务；第四种是通过Facades中的App外观解析的。除了上述几种服务解析方式，Laravel框架还实现了一种更重要的方式，即依赖注入的方式。依赖在程序中随处可见，如在实例化一个类时，需要给其构造函数传递其他类实例的参数，这就是依赖。存在依赖，就需要有依赖注入，将相应的实参赋值给形参就是依赖注入，很多时候是通过手动方式实现依赖注入的，但在大型程序中这将严重增加程序员的负担，因为程序员需要管理所有依赖并手动添加，如果修改某一个类，可能需要修改很多针对该类的依赖注入。而Laravel框架提供了依赖自动注入，也就是说只需要关注服务容器中服务的提供，对于需要依赖的地方，服务容器会根据依赖的限制自动在容器中查找要求的服务生成实参赋值给形参，实现依赖的自动注入。实现代码如下：

这里设计了一个WelcomeController控制器类，在该类的构造函数中存在依赖$generalService，而该依赖的类型是\App\ServiceTest\GeneralService类，也就是说注入的依赖必须是该类的实例，那么服务容器在创建控制器类实例的时候会检查构造函数中的依赖参数，根据依赖参数的类型查找容器中与其对应的服务名称，如果相同则会生成对应的服务并将该服务作为实参注入到控制器类的构造函数中。需要注意的是，如果在服务注册后需要使用依赖注入功能，则该服务名称和服务是需要遵守一定的规范的，即服务名称一般为服务生成的实例对象的类名称或接口名称，只有这样当服务容器根据依赖限制查找到服务后生成的实例对象才能满足这个限制，否则就会报错。依赖自动注入并不一定只是在类的构造器中可以使用，在一些方法中也可以使用，实例代码如下：

通过上述实例可以看到，在Laravel框架中既可以在构造函数中实现依赖自动注入，又可以在函数中实现依赖自动注入，那是否说在Laravel框架中任何类的构造函数和方法都可以使用这种方式实现依赖注入呢？答案是否定的，通过依赖注入的方式解决依赖关系的类和方法是需要服务容器创建的类或调用的方法，也就是说通过服务容器创建的类的构造函数可以通过依赖注入的方式解决依赖问题，因为服务容器在创建该类的实例时会检查构造函数中的依赖，所以才能实现依赖自动注入，对于方法也是一样。本实例中控制器和控制器的方法都是通过服务容器自动创建和调用的，通过接口进行服务绑定，而非通过具体类进行服务绑定，通过接口绑定实现依赖注入的代码如下：文件：laravel\app\ServiceTest\ServiceContract.php

这里\App\ServiceTest\ServiceContract实际上是一个接口，而\App\ServiceTest\General Service类实现了该接口，在服务绑定中服务名称为接口名称，服务为具体类名称，在服务容器中会自动创建生成回调函数的服务并实现绑定。通过这种服务绑定使得一个具体功能与一个接口实现了关联，在以后需要应用时通过解析该接口即可获得一个具体功能类的实例，而对于程序本身只与接口耦合，当应用需求发生变化时可以随时修改具体类，只要具体类符合接口规范，那么整个程序都不需要改变依然可以正常运行，哪怕将Laravel框架中所有的功能模块都换成其他的，只要遵循接口规范，各功能模块之间依然可以相互协作执行功能，而Laravel的接口规范定义在Illuminate\Contracts\文件夹下。