Laravel 服务容器的优势是什么？

[PHPNewbie]

刚入门 Laravel 服务容器。Laravel 的服务容器，对象的实例化由以下这种方式完成：

$obj1 = $container->make('class1', 'class2');
$obj2 = $container->make('class3', 'class4');

而以下这种方式的实例化同样可以做到：

$obj1 = new class1(new class2());
$obj2 = new class3(new class4());

那服务容器的优势到底是什么呢？ 希望大佬能够用具体例子来体现或是解释一下服务容器的优势，小的多谢了。

[Moker]

可以去看下 依赖注入和控制反转

[assad]

竟玩一些花活，框架性能烂的要死！

[mooncakejs]

优势就是 1 楼说的。 说大白话一点就是 依赖接口而不是依赖实例。 不过 php 玩这个确实有点自宫的感觉。

[zhengwenk]

其实就是所谓的依赖注入 DI 和 控制反转 IOC。

[Ouyangan]

我写 java 后端, 容器简单理解就是:不要你自己管理对象的生命周期 ,创建,销毁都交给容器来管理 . 要用的时候注入对象就好了 , 有利于代码解耦和测试 , 这个设计思想仁者见仁智者见智.
底层数据结构一般是线程安全的哈希表 .

[asen477]

浪费资源开销。。概念机的炒作
有好有坏

[random2333]

@assad laravel 的性能测试烂，和配置优化还有默认开启 session 有关系，真实性能不算差的

[abcbuzhiming]

laravel 的那套东西，如果玩过 java 的 SSH 系列的都知道是咋回事，我个人不看好，更像是“为了证明我能这样”而搞出来的产物，而且 java 系的 web 最近一直在瘦身，往轻量化方向转，那种层层包装的做法被认为落后于时代，laravel 却觉得那样很好，还要学过来。。。我实在不觉得这有什么好学的，真正 javaee 的优点在于常驻内存，这个角度上，swoole 这样的东西才是未来，laravel 还是没脱离一次请求——载入资源——处理完毕——资源卸载这种 CGI 过程，包装的再华丽有啥用

[abcbuzhiming]

@random2333 在大部分已知 PHP MVC 框架里，他最差，这还不算差是啥，其实差点倒也无所谓，关键是我觉得这家伙路走歪了

[onion83]

@abcbuzhiming 一个写页面应用，一个写底层服务，使用场景不一样，没必要吹毛求疵吧。

[sagaxu]

我现在离了容器都不会写代码了

[random2333]

@abcbuzhiming 同意过于层层包装过于复杂，用了太多的魔术方法和闭包。性能在开启 opcache 和执行优化的指令之后没有比其他框架差的

[levn]

……也算一种“元编程”了

[qiyon]

```
$log = $container->make('log')
```

并不需要知道 log 具体是什么类，可能是`/Log/DbLog`, 可能是`/Log/FileLog`

[linoder]

代码迭代速度很高 同时还得保证单元测试覆盖率 这种情况下你说说的“服务容器”优势会非常明显

[xiaotianhu]

随便可以替换掉框架种的某个类的实现

比如我想改造一下系统里的 mysql 类 不用去动框架的代码

随便找个文件夹写好 注册到容器里就替换了。不耽误升级

[abcbuzhiming]

@onion83 不，你没明白我说的意思，和他们的应用方向无关，而是常驻内存这个关键。近年来 CGI 模式以请求——脚本载入——执行完毕——卸载的方式，受到了 jit 等模式的挑战，javaee 重新开始回暖某种程度上可以视为业界的一种态度，swoole 从设计上是常驻内存的，而 php7 虽然有了围绕 opcache 设计的 jit，但是这玩意在 CGI 模式下真是常驻内存的吗，我鲜有看到这方面的描述。

[abcbuzhiming]

@random2333 有证据吗？网上评测速度慢的证据很多，开了 opcache 和优化后速度上来的证据好像没找到

[random2333]

http://www.golaravel.com/post/benchmarking-laravel-symfony-zend/ 可以看下这个，然后测试一下和原生 php 的差距 @abcbuzhiming

[z5864703]

@abcbuzhiming 常驻内存的话，就得对资源使用精打细算了，php 快速开发有一个优势就是大部分场景不用考虑垃圾回收
Laravel 的优势就是可以快速搭建一套网站，swoole 写整套网站要疯。
使用场景都不一样
麻烦深入了解和理解下各个语言与框架，以及运行机制吧

[onion83]

@abcbuzhiming fastcgi 或者说 php-fpm 本来就是用于快速处理请求而生的，常见用于 web。在这种模式下通常会有一个最长的执行时间，超时或者 core 的时候会被 master 从进程池回收掉。

fastcgi 的应用场景：对业务完整容忍度要求相对低，业务复杂且外部调用不可控（ db\network\file ），业务初期快速开发。但缺点是没有原生的连接池，无法实现资源共享，进程间只能通过 apcu 扩展进行内存共享。

swoole/workman (daemon) 的应用场景：业务稳定，需要更为底层的 handle tcp 状态 ,需要精确把握每个细节。常用于 tcp / websocket server 等开发。好处是：worker 之间通过静态类变量 /table/Atomic 甚至是 global 进行共享，程序性能实现最大化。缺点是，对开发人员要求较高，原本同步的代码会变为异步，增加复杂度，部署相对不便。

综上述：我认为因为应用场景的不同，我认为是否常驻内存不是关键。

Laravel 是一个应用层的开发框架，swoole (cli) / nginx+php-fpm / apache+mod-php 只是 php 运行的一种模式，Zend Optimizer/JIT 更是语言编译器的东西。三者根本不是一个维度的东西，没有什么好比较的，而且谁说 Laravel 不能在 swoole 在上面跑？

问题 1:
“近年来 CGI 模式以请求——脚本载入——执行完毕——卸载的方式，受到了 jit 等模式的挑战 ……”
错误，不是一个维度的东西，挑战什么？

问题 2:
“ swoole 从设计上是常驻内存的……”
应为以 daemon 的形式常驻系统，代码一次载入（编译）长期运行，能享受到 opcache/jit 的红利。

问题 3:
“这玩意在 CGI 模式下真是常驻内存的吗，我鲜有看到这方面的描述 ……”
请尝试 Google “ php-fpm share opcache ”

[leunggamciu]

使用容器来`make`一个实例和手动`new`一个实例最主要的区别是在于依赖的解决。使用`new`，你需要手动传递所有必需的依赖；而使用`make`，当依赖被提前配置好的情况下，容器会帮你解决这部分依赖。这个和接口应该没有什么关系吧

[iVanilla]

@abcbuzhiming 比性能更差？ Symfony 和 Zend Framework 表示不服

[hhxsv5]

Swoole 来拯救低性能的 Laravel，LaravelS github.com/hhxsv5/laravel-s 有兴趣可尝试下。