Configuration de l'injection de dépendances

Aperçu des options de configuration pour le conteneur Nette DI.

Fichier de configuration

Le conteneur Nette DI est facilement contrôlé à l'aide de fichiers de configuration. Ceux-ci sont généralement écrits au format NEON. Pour l'édition, nous recommandons des éditeurs avec support pour ce format.

 decorator: 	Décorateur
 di: 			Conteneur DI
 extensions: 	Installation d'extensions DI supplémentaires
 includes: 	Inclusion de fichiers
 parameters: 	Paramètres
 search: 		Enregistrement automatique des services
 services: 		Services

Pour écrire une chaîne contenant le caractère %, vous devez l'échapper en le doublant en %%.

Paramètres

Dans la configuration, vous pouvez définir des paramètres qui peuvent ensuite être utilisés dans le cadre des définitions de service. Cela peut clarifier la configuration ou unifier et isoler les valeurs qui changeront.

parameters:
	dsn: 'mysql:host=127.0.0.1;dbname=test'
	user: root
	password: secret

Nous nous référons au paramètre dsn n'importe où dans la configuration en écrivant %dsn%. Les paramètres peuvent également être utilisés à l'intérieur de chaînes comme '%wwwDir%/images'.

Les paramètres ne doivent pas nécessairement être des chaînes ou des nombres, ils peuvent également contenir des tableaux :

parameters:
	mailer:
		host: smtp.example.com
		secure: ssl
		user: franta@gmail.com
	languages: [cs, en, de]

Nous nous référons à une clé spécifique comme %mailer.user%.

Si vous avez besoin de connaître la valeur d'un paramètre dans votre code, par exemple dans une classe, passez-le à cette classe. Par exemple, dans le constructeur. Il n'existe pas d'objet global représentant la configuration que les classes interrogeraient pour les valeurs des paramètres. Cela violerait le principe d'injection de dépendances.

Services

Voir le chapitre séparé.

Decorator

Comment modifier en masse tous les services d'un certain type ? Par exemple, appeler une certaine méthode sur tous les presenters qui héritent d'un ancêtre commun spécifique ? C'est là qu'intervient le décorateur.

decorator:
	# pour tous les services qui sont des instances de cette classe ou interface
	App\Presentation\BasePresenter:
		setup:
			- setProjectId(10)       # appelle cette méthode
			- $absoluteUrls = true   # et définit la variable

Le décorateur peut également être utilisé pour définir des tags ou activer le mode inject.

decorator:
	InjectableInterface:
		tags: [mytag: 1]
		inject: true

DI

Paramètres techniques du conteneur DI.

di:
	# afficher le DIC dans la barre Tracy ?
	debugger: ...        # (bool) par défaut est true

	# types de paramètres à ne jamais autowirer
	excluded: ...        # (string[])

	# autoriser la création paresseuse de services ?
	lazy: ...            # (bool) par défaut est false

	# classe dont hérite le conteneur DI
	parentClass: ...     # (string) par défaut est Nette\DI\Container

Services paresseux

Le paramètre lazy: true active la création paresseuse (différée) des services. Cela signifie que les services ne sont pas réellement créés au moment où nous les demandons au conteneur DI, mais seulement au moment de leur première utilisation. Cela peut accélérer le démarrage de l'application et réduire l'empreinte mémoire, car seuls les services réellement nécessaires dans la requête donnée sont créés.

Pour un service spécifique, la création paresseuse peut être modifiée.

Les objets paresseux ne peuvent être utilisés que pour les classes utilisateur, pas pour les classes PHP internes. Nécessite PHP 8.4 ou plus récent.

Exportation des métadonnées

La classe du conteneur DI contient également beaucoup de métadonnées. Vous pouvez la réduire en réduisant l'exportation des métadonnées.

di:
	export:
		# exporter les paramètres ?
		parameters: false   # (bool) par défaut est true

		# exporter les tags et lesquels ?
		tags:               # (string[]|bool) par défaut tous
			- event.subscriber

		# exporter les données pour l'autowiring et lesquelles ?
		types:              # (string[]|bool) par défaut toutes
			- Nette\Database\Connection
			- Symfony\Component\Console\Application

Si vous n'utilisez pas le tableau $container->getParameters(), vous pouvez désactiver l'exportation des paramètres. De plus, vous pouvez exporter uniquement les tags via lesquels vous obtenez des services avec la méthode $container->findByTag(...). Si vous n'appelez pas du tout la méthode, vous pouvez désactiver complètement l'exportation des tags en utilisant false.

Vous pouvez réduire considérablement les métadonnées pour l'autowiring en listant les classes que vous utilisez comme paramètre de la méthode $container->getByType(). Et encore une fois, si vous n'appelez pas du tout la méthode (ou seulement dans le bootstrap pour obtenir Nette\Application\Application), vous pouvez désactiver complètement l'exportation en utilisant false.

Extensions

Enregistrement d'extensions DI supplémentaires. De cette manière, nous ajoutons par exemple l'extension DI Dibi\Bridges\Nette\DibiExtension22 sous le nom dibi

extensions:
	dibi: Dibi\Bridges\Nette\DibiExtension22

Ensuite, nous la configurons dans la section dibi :

dibi:
	host: localhost

Une classe avec des paramètres peut également être ajoutée comme extension :

extensions:
	application: Nette\Bridges\ApplicationDI\ApplicationExtension(%debugMode%, %appDir%, %tempDir%/cache)

Inclusion de fichiers

Nous pouvons inclure d'autres fichiers de configuration dans la section includes :

includes:
	- parameters.php
	- services.neon
	- presenters.neon

Le nom parameters.php n'est pas une faute de frappe, la configuration peut également être écrite dans un fichier PHP qui la renvoie sous forme de tableau :

<?php
return [
	'database' => [
		'main' => [
			'dsn' => 'sqlite::memory:',
		],
	],
];

Si des éléments avec les mêmes clés apparaissent dans les fichiers de configuration, ils seront écrasés ou, dans le cas de tableaux fusionnés. Le fichier inclus plus tard a une priorité plus élevée que le précédent. Le fichier dans lequel la section includes est listée a une priorité plus élevée que les fichiers qu'il inclut.

Search

L'ajout automatique de services au conteneur DI rend le travail extrêmement agréable. Nette ajoute automatiquement les presenters au conteneur, mais il est facile d'ajouter également d'autres classes.

Il suffit d'indiquer dans quels répertoires (et sous-répertoires) les classes doivent être recherchées :

search:
	-	in: %appDir%/Forms
	-	in: %appDir%/Model

Cependant, nous ne voulons généralement pas ajouter absolument toutes les classes et interfaces, nous pouvons donc les filtrer :

search:
	-	in: %appDir%/Forms

		# filtrage par nom de fichier (string|string[])
		files:
			- *Factory.php

		# filtrage par nom de classe (string|string[])
		classes:
			- *Factory

Ou nous pouvons sélectionner des classes qui héritent ou implémentent au moins une des classes listées :

search:
	-	in: %appDir%
		extends:
			- App\*Form
		implements:
			- App\*FormInterface

Il est également possible de définir des règles d'exclusion, c'est-à-dire des masques de nom de classe ou des ancêtres héréditaires, qui, s'ils correspondent, empêchent l'ajout du service au conteneur DI :

search:
	-	in: %appDir%
		exclude:
			files: ...
			classes: ...
			extends: ...
			implements: ...

Des tags peuvent être définis pour tous les services :

search:
	-	in: %appDir%
		tags: ...

Fusion

Si des éléments avec les mêmes clés apparaissent dans plusieurs fichiers de configuration, ils seront écrasés ou, dans le cas de tableaux, fusionnés. Le fichier inclus plus tard a une priorité plus élevée que le précédent.

config1.neon	config2.neon	résultat
`items: - 1 - 2`	`items: - 3`	`items: - 1 - 2 - 3`

Pour les tableaux, la fusion peut être empêchée en ajoutant un point d'exclamation après le nom de la clé :

config1.neon	config2.neon	résultat
`items: - 1 - 2`	`items!: - 3`	`items: - 3`