A service container (aka Dependency Injection Container, DIC) is a special object that facilitates dependency resolution. It is based on the dependency injection design pattern.
Dependency injection proposes to inject all needed objects and configuration into your business logic objects (known as services). It avoids the massive use of singletons, global variables or complicated factories and makes your code much more readable and testable.
The main issue with this pattern is how to resolve the dependencies for your services. This is where the service container comes into play. The role of a service container is to build and maintain your services and their dependencies. Each time you need a service, you may ask the service container for it. It will either build the service with the configuration you provided, or give you an existing instance if it is already available.
Ibexa DXP uses the Symfony service container.
To learn more about the service container, see:
Service tags in Symfony DIC are a useful way of dedicating services to a specific purpose. They are usually used for extension points.
For instance, if you want to register a Twig extension to add custom filters,
you need to create the PHP class and declare it as a service in the DIC configuration with the
(see the Symfony cookbook entry for a full example).
Ibexa DXP exposes several features this way (see the list of core service tags). This is for example the case with Field Types.
You will find all service tags exposed by Symfony in its reference documentation.
Core and API¶
||Adds a specific router to the chain router|
||Registers a template loader for Twig|
||Registers a ContentViewProvider for template selection depending on content/Location being viewed|
||Registers a storage engine in the Repository factory|
||Registers a Field Type|
||Registers a converter for a Field Type in Legacy storage engine|
||Registers an external storage handler for a Field Type|
||Registers an external storage gateway for a Field Type in Legacy storage engine|