搜索dhii / services-interface
与Service Provider规范兼容的服务接口
Requires
- php: ^7.1 | ^8.0
Requires (Dev)
- phpunit/phpunit: ^7.0 | ^8.0 | ^9.0
- slevomat/coding-standard: ^6.0
- vimeo/psalm: ^4.0
- webmozart/path-util: ^2.3@stable
This package is auto-updated.
Last update: 2024-09-16 13:50:03 UTC
README
与Service Provider规范兼容的服务接口。
详情
使用此接口来增强您的服务，以便可以构建依赖图。这为许多功能铺平了道路，包括
- 可视化所有应用服务的依赖图。
- 如果依赖项未满足，则发出通知。
- 建议可能满足未满足依赖项的模块包。
与dhii/services一起使用，使用方便的简写和类型信息来增强您的服务。
原理
当前服务的签名只是一个形式为 (ContainerInterface $c) => mixed 的可调用对象。这描述了服务本身，并允许它从容器中获取依赖。然而，为了知道任何特定服务定义使用了哪些其他服务，必须首先调用该定义。这意味着按照目前的情况，如果不实际执行所有操作，就无法构建所有服务关系的映射。
解决方案是使服务意识到并能够公开它所依赖的其他服务的名称。这样，就可以创建一个相当统一的算法，可以记录所有这些关系，并构建所有服务和它们依赖的完整图。这为检测和自动化开辟了新的可能性。
如Factory之类的实现可以声明其依赖项，并在将其传递给服务定义之前自动解决它们，这使得可以描述期望依赖项的类型。这还减少了需要编写的代码量，不仅消除了类型检查/断言，还消除了对 $c->get() 的调用。同时，这种方法加强了严格性，因为服务定义不再有选择检索或不检索其依赖项的选择：所有依赖项都声明并必须在定义有机会执行任何操作之前解决。这使得图更稳定，并减少了隐藏依赖项的机会，这些依赖项可能不会在其他情况下显示，例如仅记录从容器中检索到的所有服务名称。
withDependencies() 方法启用多装箱，允许在同一个应用程序中多次使用相同的服务提供者 - 可能具有不同的前缀。这不仅避免了手动重新声明已定义的服务，还有可能解决服务名称冲突问题，并且不再需要为提供者中的服务名称想出聪明的前缀，而是将部分责任转移到应用程序。这是好事，因为它进一步强调了应用程序控制的概念 - 类似于应用程序决定哪些服务覆盖哪些服务，如何发现和加载提供者等。