How to Create Service Aliases and Mark Services as Private
Warning: You are browsing the documentation for Symfony 2.x, which is no longer maintained.
Read the updated version of this page for Symfony 7.2 (the current stable version).
Marking Services as Public / Private
When defining services, you'll usually want to be able to access these definitions
within your application code. These services are called public. For
example, the doctrine
service is a public service. This means that you can
fetch it from the container using the get()
method:
1
$doctrine = $container->get('doctrine');
In some cases, a service only exists to be injected into another service and is not intended to be fetched directly from the container as shown above.
In these cases, to get a minor performance boost, you can set the service to be not public (i.e. private):
1 2 3 4
services:
foo:
class: Example\Foo
public: false
What makes private services special is that, if they are only injected once,
they are converted from services to inlined instantiations (e.g. new PrivateThing()
).
This increases the container's performance.
Now that the service is private, you must not fetch the service directly from the container:
1
$container->get('foo');
Simply said: A service can be marked as private if you do not want to access it directly from your code.
However, if a service has been marked as private, you can still alias it (see below) to access this service (via the alias).
Note
Services are by default public, but it's considered a good practice to mark as many services private as possible.
Aliasing
You may sometimes want to use shortcuts to access some services. You can do so by aliasing them and, furthermore, you can even alias non-public services.
1 2 3 4 5 6
services:
app.phpmailer:
class: AppBundle\Mail\PhpMailer
app.mailer:
alias: app.phpmailer
This means that when using the container directly, you can access the
app.phpmailer
service by asking for the app.mailer
service like this:
1
$container->get('app.mailer'); // Would return a PhpMailer instance
Tip
In YAML, you can also use a shortcut to alias a service:
1 2 3
services:
# ...
app.mailer: '@app.phpmailer'
Anonymous Services
Note
Anonymous services are only supported by the XML configuration format.
In some cases, you may want to prevent a service being used as a dependency of other services. This can be achieved by creating an anonymous service. These services are like regular services but they don't define an ID and they are created where they are used.
The following example shows how to inject an anonymous service into another service:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
<!-- app/config/services.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<container xmlns="http://symfony.com/schema/dic/services"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://symfony.com/schema/dic/services
http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<service id="foo" class="AppBundle\Foo">
<argument type="service">
<service class="AppBundle\AnonymousBar" />
</argument>
</service>
</services>
</container>
Deprecating Services
2.8
The deprecated
option was introduced in Symfony 2.8.
Once you have decided to deprecate the use of a service (because it is outdated or you decided not to maintain it anymore), you can deprecate its definition:
1 2 3
acme.my_service:
class: ...
deprecated: The "%service_id%" service is deprecated since 2.8 and will be removed in 3.0.
Now, every time this service is used, a deprecation warning is triggered, advising you to stop or to change your uses of that service.
The message is actually a message template, which replaces occurrences of the
%service_id%
placeholder by the service's id. You must have at least one
occurrence of the %service_id%
placeholder in your template.
Note
The deprecation message is optional. If not set, Symfony will show this default
message: The "%service_id%" service is deprecated. You should stop using it,
as it will soon be removed.
.
Tip
It is strongly recommended that you define a custom message because the default one is too generic. A good message informs when this service was deprecated, until when it will be maintained and the alternative services to use (if any).
For service decorators (see above), if the definition does not modify the deprecated status, it will inherit the status from the definition that is decorated.