The documentation you are viewing is for an older version of this component.
Switch to the latest (v3) version.
In This Article
Expressive promotes and advocates the usage of Dependency Injection/Inversion of Control (also referred to as DI — or DIC — and IoC, respectively) containers when writing your applications. These should be used for the following:
Defining application dependencies: routers, template engines, error handlers, even the
Defining middleware and related dependencies.
Application instance itself stores a container, from which it fetches
middleware when ready to dispatch it; this encourages the idea of defining
middleware-specific dependencies, and factories for ensuring they are injected.
To facilitate this and allow you as a developer to choose the container you prefer, zend-expressive typehints against PSR-11 Container, and throughout this manual, we attempt to show using a variety of containers in examples.
At this time, we document support for the following specific containers:
We recommend using fully-qualified class names whenever possible as service names, with one exception: in cases where a service provides an implementation of an interface used for typehints, use the interface name.
Following these practices encourages the following:
- Consumers have a reasonable idea of what the service should return.
- Using interface names as service names promotes re-use and substitution.
In a few cases, we define "virtual service" names. These are cases where there is no clear typehint to follow (e.g., most middleware only uses
callableas a typehint, or where we want to imply specific configuration is necessary (e.g., Whoops requires specific configuration to work correctly with Expressive, and thus we do not want a generic service name for it). We try to keep these to a minimum, however.
Found a mistake or want to contribute to the documentation? Edit this page on GitHub!