这是一个创建于 2705 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚入门 Laravel 服务容器。Laravel 的服务容器，对象的实例化由以下这种方式完成：
$obj1 = $container->make('class1', 'class2');
$obj2 = $container->make('class3', 'class4');
而以下这种方式的实例化同样可以做到：
$obj1 = new class1(new class2());
$obj2 = new class3(new class4());
那服务容器的优势到底是什么呢？ 希望大佬能够用具体例子来体现或是解释一下服务容器的优势，小的多谢了。
 |
1
Moker 2017-06-30 11:17:03 +08:00
可以去看下 依赖注入和控制反转
|
 |
2
assad 2017-06-30 11:21:42 +08:00
竟玩一些花活，框架性能烂的要死！
|
 |
3
mooncakejs 2017-06-30 11:25:22 +08:00  1
优势就是 1 楼说的。 说大白话一点就是 依赖接口而不是依赖实例。 不过 php 玩这个确实有点自宫的感觉。
|
 |
4
zhengwenk 2017-06-30 11:28:35 +08:00
其实就是所谓的依赖注入 DI 和 控制反转 IOC。
|
 |
5
Ouyangan 2017-06-30 11:47:22 +08:00 2
我写 java 后端, 容器简单理解就是:不要你自己管理对象的生命周期 ,创建,销毁都交给容器来管理 . 要用的时候注入对象就好了 , 有利于代码解耦和测试 , 这个设计思想仁者见仁智者见智.
底层数据结构一般是线程安全的哈希表 . |
 |
6
asen477 2017-06-30 12:00:00 +08:00 1
浪费资源开销。。概念机的炒作
有好有坏 |
 |
7
random2333 2017-06-30 13:33:32 +08:00
@assad laravel 的性能测试烂，和配置优化还有默认开启 session 有关系，真实性能不算差的
|
 |
8
abcbuzhiming 2017-06-30 14:16:14 +08:00 1
laravel 的那套东西，如果玩过 java 的 SSH 系列的都知道是咋回事，我个人不看好，更像是“为了证明我能这样”而搞出来的产物，而且 java 系的 web 最近一直在瘦身，往轻量化方向转，那种层层包装的做法被认为落后于时代，laravel 却觉得那样很好，还要学过来。。。我实在不觉得这有什么好学的，真正 javaee 的优点在于常驻内存，这个角度上，swoole 这样的东西才是未来，laravel 还是没脱离一次请求——载入资源——处理完毕——资源卸载这种 CGI 过程，包装的再华丽有啥用
|
|
9
abcbuzhiming 2017-06-30 14:17:39 +08:00
@random2333 在大部分已知 PHP MVC 框架里，他最差，这还不算差是啥，其实差点倒也无所谓，关键是我觉得这家伙路走歪了
|
 |
10
onion83 2017-06-30 14:20:13 +08:00
@abcbuzhiming 一个写页面应用，一个写底层服务，使用场景不一样，没必要吹毛求疵吧。
|
 |
11
sagaxu 2017-06-30 14:24:50 +08:00
我现在离了容器都不会写代码了
|
|
12
random2333 2017-06-30 14:25:00 +08:00
@abcbuzhiming 同意过于层层包装过于复杂，用了太多的魔术方法和闭包。性能在开启 opcache 和执行优化的指令之后没有比其他框架差的
|
 |
13
levn 2017-06-30 14:56:45 +08:00
……也算一种“元编程”了
|
 |
14
qiyon 2017-06-30 16:45:20 +08:00
```
$log = $container->make('log') ``` 并不需要知道 log 具体是什么类，可能是`/Log/DbLog`, 可能是`/Log/FileLog` |
 |
15
linoder 2017-07-01 01:34:40 +08:00
代码迭代速度很高 同时还得保证单元测试覆盖率 这种情况下你说说的“服务容器”优势会非常明显
|
 |
16
xiaotianhu 2017-07-01 09:59:31 +08:00 via iPhone
随便可以替换掉框架种的某个类的实现
比如我想改造一下系统里的 mysql 类 不用去动框架的代码 随便找个文件夹写好 注册到容器里就替换了。不耽误升级 |
|
17
abcbuzhiming 2017-07-02 22:44:25 +08:00
@onion83 不，你没明白我说的意思，和他们的应用方向无关，而是常驻内存这个关键。近年来 CGI 模式以请求——脚本载入——执行完毕——卸载的方式，受到了 jit 等模式的挑战，javaee 重新开始回暖某种程度上可以视为业界的一种态度，swoole 从设计上是常驻内存的，而 php7 虽然有了围绕 opcache 设计的 jit，但是这玩意在 CGI 模式下真是常驻内存的吗，我鲜有看到这方面的描述。
|
|
18
abcbuzhiming 2017-07-02 22:45:39 +08:00
@random2333 有证据吗？网上评测速度慢的证据很多，开了 opcache 和优化后速度上来的证据好像没找到
|
|
19
random2333 2017-07-02 23:03:27 +08:00
http://www.golaravel.com/post/benchmarking-laravel-symfony-zend/ 可以看下这个，然后测试一下和原生 php 的差距 @abcbuzhiming
|
 |
20
z5864703 2017-07-03 11:14:25 +08:00
@abcbuzhiming 常驻内存的话，就得对资源使用精打细算了，php 快速开发有一个优势就是大部分场景不用考虑垃圾回收
Laravel 的优势就是可以快速搭建一套网站，swoole 写整套网站要疯。 使用场景都不一样 麻烦深入了解和理解下各个语言与框架，以及运行机制吧 |
|
21
onion83 2017-07-03 11:56:36 +08:00 1
@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 ” |
 |
22
leunggamciu 2017-07-03 13:09:15 +08:00
使用容器来`make`一个实例和手动`new`一个实例最主要的区别是在于依赖的解决。使用`new`，你需要手动传递所有必需的依赖；而使用`make`，当依赖被提前配置好的情况下，容器会帮你解决这部分依赖。这个和接口应该没有什么关系吧
|
 |
23
iVanilla 2017-07-03 13:22:07 +08:00 via Android
@abcbuzhiming 比性能更差？ Symfony 和 Zend Framework 表示不服
|
 |
24
hhxsv5 2018-01-31 17:10:52 +08:00
Swoole 来拯救低性能的 Laravel，LaravelS github.com/hhxsv5/laravel-s 有兴趣可尝试下。
|
Select Language