container-interop / container-interop
Requires
- psr/container: ^1.0
This package is auto-updated.
Last update: 2019-11-19 14:21:29 UTC
README
弃用警告!
从2017年2月13日起,container-interop 正式被弃用,转而支持 PSR-11。container-interop曾是PSR-11的试验场。从v1.2开始,container-interop直接扩展PSR-11接口。因此,所有实现container-interop的容器现在实际上是兼容PSR-11的。
- 实现container-interop接口的项目鼓励直接实现PSR-11接口。
- 消费container-interop接口的项目强烈建议直接对PSR-11接口进行类型提示,以兼容不兼容container-interop的PSR-11容器。
关于代理查找功能,该功能存在于container-interop中而不存在于PSR-11中,实际上是一种设计模式。因此,它没有被弃用。关于此设计模式的文档将在未来迁移到独立的网站。
关于
container-interop试图识别和标准化容器对象(服务定位器、依赖注入容器等)中的功能,以实现互操作性。
通过讨论和试验,我们试图创建一个由常见接口和推荐组成的规范。
如果提供容器实现的PHP项目开始采用这些通用标准,那么使用容器的PHP应用程序和项目就可以依赖于这些通用接口,而不是特定的实现。这有助于实现高度的互操作性和灵活性,使用户可以消费任何可以适应这些接口的容器实现。
本项目的工作并未得到PHP-FIG的官方支持,但它是由PHP-FIG成员和其他优秀开发者共同完成的。我们遵循PHP-FIG的精神和理念,希望这个项目能为一个或多个未来的PSR铺平道路。
安装
您可以通过Composer安装此包。
composer require container-interop/container-interop
该包遵循SemVer规范,并且将在小版本之间保持完全向后兼容。
规范
可用的
ContainerInterface
. 描述 元文档. 描述了一个暴露读取其条目的方法容器的接口。- 委托查找功能. 元文档. 介绍了容器将依赖项的查找委托给第三方容器的功能。此功能允许多个容器在单个应用程序中协同工作。
建议
查看开放的 请求评论
兼容项目
实现 ContainerInterface
的项目
- Acclimate: 为 Aura.Di、Laravel、Nette DI、Pimple、Symfony DI、ZF2 服务管理器、ZF2 依赖注入以及任何使用
ArrayAccess
的容器提供适配器 - Aura.Di
- auryn-container-interop
- Burlap
- Chernozem
- 数据管理器
- Disco
- InDI
- League/Container
- Mouf
- Njasm Container
- PHP-DI
- Picotainer
- PimpleInterop
- Pimple3-ContainerInterop(使用 Pimple v3)
- SitePoint 容器
- Thruster Container(仅限 PHP7)
- Ultra-Lite 容器
- Unbox
- XStatic
- Zend 服务管理器
- Zit
实现 委托查找 功能的项目
实现 ContainerInterface
的中间件
- Alias-Container: 为任何容器添加别名支持
- Prefixer-Container: 动态添加标识符前缀
- Lazy-Container: 懒加载服务
使用 ContainerInterface
的项目
以下列表仅包含所有消耗 ContainerInterface
的项目的样本。要获取更完整的列表,请查看 这里。
下载 | |
---|---|
Adroit | |
Behat | |
blast-facades:最小化复杂性,将依赖项表示为外观。 | |
interop.silex.di:Silex 的扩展,支持任何 container-interop 兼容的容器 | |
mindplay/walkway:模块化请求路由器 | |
mindplay/middleman:极简 PSR-7 中间件调度器 | |
PHP-DI/Invoker:可扩展和可配置的调用器/调度器 | |
Prophiler | |
Silly:CLI 微框架 | |
Slim v3 | |
Splash | |
Woohoo Labs. Harmony:一个灵活的微框架 | |
zend-expressive |
工作流程
每个人都欢迎加入并贡献力量。
一般工作流程如下
- 有人打开一个讨论(GitHub 问题)来提出一个接口
- 收集反馈
- 将接口添加到开发分支
- 我们发布alpha版本,以便进行界面实验
- 随后进行讨论和编辑,直到界面被普遍认为稳定
- 发布包的新小版本
我们尝试通过创建新接口而不是编辑现有接口来不破坏BC。
虽然我们目前专注于界面,但我们对所有可能有助于互操作性的事物持开放态度,无论是代码、最佳实践等。