10 \ August 2019 \ http://www.phparch.comSymfony 4: A New Way to Develop ApplicationsThis was the minimum requirement for service. These files
can often be found within Symfony bundles, and are nothing
more than a (long) list of services and their corresponding
classes. Once Symfony collected all these services, it compiled
a service container with all services which would then be
used within your Symfony project. By default, all services
were public, which is slower than having private services.
Well, not that much slower but still slower. When calling a
service, Symfony tries to find the corresponding name in this
service container, instantiate the corresponding class if not
done so already, and returns it for you to use. Simple right?
Also, no magic.
The same process is happening with autowiring. The first
thing is that Symfony creates services from classes automat-
ically without specifying this inside your services.yml file.
Symfony cannot know what you like to call those services (like
renderer or mailer), but instead, it registers each class it finds
as the fully qualified class name (FQCN). Our mailer service
would automatically be registered as the service AppBundle\
Service\MailerService. Since we use a type hint to an object,
PHP expects you to pass a \AppBundle\Service\RenderService
instance to this constructor. During autowiring, Symfony
looks in the service container to see if there is such a service
defined. If so, it automatically injects that specific service
into the constructor, even though you haven’t configured this
service and added any arguments to it. This is what Symfony’s
autowiring functionality is all about: Symfony automaticallywires the dependencies based on their fully qualified class
name.
If we check the Symfony config file in config/services.yaml
shown in Listing 5, we see that autowiring is enabled by default.
You can turn this off if you want, but there is no reason to do
this configuration manually. In the end, it is the same thing,
and you save a lot of your precious time using autowiring. In
the configuration, we can see that all classes are available to
be used as services except classes defined under:../src/{DependencyInjection,Entity,Migrations,Tests,Kernel.php}Also, we can see all the classes in the ./Controller folder are
registered as services and tagged as controllers. This is very
important as this allows us to use autowiring and injections
inside controller classes. Autoconfiguration is closely related
to autowiring. Where autowiring automatically connects any
dependencies to services, autoconfiguration configures those
services automatically. This isn’t always needed, but you often
see autoconfiguration used for automatically adding tags to
services, like in default configuration file.Listing 5
Symfony default config file
This file is the entry point to configure your own services.
Files in the packages/ subdirectory configure your dependencies.
Put parameters here that don't need to change on each machine where the app is deployed.
https://symfony.com/doc/current/best_practices/configuration.html#application-related-configuration
- parameters:
- services:
default configuration for services in this file
- _defaults:
- autowire: true # Automatically injects dependencies in your services.
- autoconfigure: true # Automatically registers your services as commands, event subscribers, etc.
makes classes in src/ available to be used as services
this creates a service per class whose id is the fully-qualified class name
- App\:
- resource: '../src/*'
- exclude: '../src/{DependencyInjection,Entity,Migrations,Tests,Kernel.php}'
controllers are imported separately to make sure services can be injected
as action arguments even if you don't extend any base controller class
- App\Controller\:
- resource: '../src/Controller'
- tags: ['controller.service_arguments']
add more service definitions when explicit configuration is needed
please note that last definitions always replace previous ones