|
|
Publié sur 30/08/2018 13:29:41
|
|
|
Aujourd’hui, j’ai discuté avec mes collègues pour savoir s’il fallait utiliser une combinaison de @Configuration et de @Bean pour créer des haricots dans Spring Boot ou s’il fallait utiliser directement @Service et autres annotations sur le cours. L’auteur a tendance à utiliser la première, c’est-à-dire une combinaison de @Configuration et de @Bean.
Prenons d’abord un exemple : l’objectif est de créer un grain pour le SearchService.
Utilisez-@Service directement :
Démarrez l’application, accès au navigateur : http://localhost:8081/search?q=koly, affichage de la page : [« hello », « koly »]
Façons d’utiliser @Configuration et @Bean :
Comparé à l’utilisation directe de @Service code, il existe une classe AppConfig qui supprime les annotations @Service placées au-dessus d’ElasticSearchServiceImpl. À première vue, il y a plus de code et de classes. Alors, quels sont les avantages d’utiliser ce dernier ?
L’auteur estime que les avantages sont les suivants :
Séparation des intérêts
En utilisant des méthodes @Configuration et @Bean, la création des grains se fait au même endroit, et l’interface et sa mise en œuvre n’ont rien à voir avec la création du grain.
Si la création du bean doit être modifiée, il suffit de visualiser et de modifier la classe Configuration correspondante, et il n’est pas nécessaire d’aller sur le bean Java correspondant pour effectuer des modifications. Par exemple, parfois la création de beans doit être coopérée avec @Scope ou @Profile, et il suffit de modifier la classe Configuration.
Mission unique
@service annotation elle-même assume deux responsabilités :
L’une est la création de haricots ;
La seconde consiste à identifier une classe comme un service.
Indique qu’une classe annotée est un « Service », initialement défini par Domain-Driven
Design (Evans, 2003) comme « une opération proposée comme une interface qui se tient seule dans le modèle, sans état encapsulé. »
Voici l’explication de Spring sur @Service annotations. Cette is@Service représente en fait une opération d’interface indépendante et sans état dans DDD.
Dans le cadre de @Bean et de coopération @Configuration, la création des haricots est confiée à une classe distincte, et l’identité de Service est transmise à l’interface et au nom de la classe en Java. Cela se reflète également dans Spring Data, comme Repository, qui est identifié par son nom, comme CrudRepository. Par conséquent, le terme Service est également reflété par le nom. Des définitions hiérarchiques spécifiques peuvent être utilisées pour fournir plus de couches selon le projet par son nom, sans dépendre des annotations fournies par Spring, telles que le calque Mapper, le calque Validator, etc.
De plus, « haricot » et service sont des concepts bidimensionnels. L’un sur la mise en œuvre concrète et l’autre sur les concepts de DDD.
Plus flexible
En utilisant @Bean méthodes, vous pouvez créer des instances de classes dans la bibliothèque. Si vous utilisez la méthode @Service, vous ne pourrez pas ajouter @Service commentaires aux classes correspondantes dans la bibliothèque.
Moins de connaissances
Le principe de connaissance minimale signifie :
Moins il y a de technologie ou de connaissances nécessaires pour accomplir la fonction, mieux c’est, afin d’assurer la simplicité du projet et de réduire la difficulté d’apprentissage.
Comme il n’est pas possible de créer des instances de classes dans la bibliothèque de classes en utilisant @Service, il faut utiliser la forme de @Configuration et @Bean lorsque vous rencontrez des besoins similaires. À ce stade, il y a des annotations telles que @Service, @Configuration et @Bean dans tout le projet, et ces annotations font la même chose, c’est-à-dire créer le grain.
Avec @Service, il y a une forte probabilité de @Service, @Component, @Configuration et @Bean en même temps.
tout en utilisant @Configuration et @Bean peut complètement éliminer l’utilisation de @Service et @Component, ce qui est conforme au principe de connaissance minimale.
Enfin, d’ailleurs, les Spring Beans ont été créés en XML et ont ensuite utilisé Java pour la configuration. La principale raison de ne pas utiliser XML est qu’il n’est pas assez concis et ne propose pas de fonctionnalités telles que la vérification au moment de la compilation, plutôt que la nécessité de répartir la création de beans entre classes.
En résumé, l’auteur préfère utiliser @Configuration et @Bean méthodes. |
Précédent:Une façon simple de vider l’écran depuis la ligne de commande PythonProchain:Plusieurs façons d’utiliser les verrous distribués (redis, zookeeper, base de données)
|
