@Component est équivalent à
@Service, @Controller, @Repository = {@Component + quelques fonctionnalités spéciales supplémentaires}
Cela signifie que Service, Le Controller et le Repository sont fonctionnellement les mêmes.
Les trois annotations sont utilisées pour séparer les "couches" de votre application,
- Les contrôleurs font des choses comme la répartition, la redirection, l'appel de méthodes de service, etc.
- Les services contiennent la logique métier, les calculs, etc.
- Les référentiels sont les DAO (Data Access Objects), ils accèdent directement à la base de données.
Maintenant, vous pouvez vous demander pourquoi les séparer : (Je suppose que vous connaissez la POA - Programmation Orientée Aspect)
Disons que vous souhaitez surveiller l'activité de la couche DAO uniquement. Vous allez écrire une classe Aspect qui fait un journal avant et après chaque méthode de votre DAO invoquée, vous pouvez le faire en utilisant la POA car vous avez trois couches distinctes et ne sont pas mélangées.
Vous pouvez donc journaliser les méthodes DAO "autour", "avant" ou "après" l'appel des méthodes DAO. Vous pourriez le faire parce que vous aviez un DAO en premier lieu. Ce que vous venez de réaliser est la séparation des préoccupations ou des tâches.
Imaginez s'il n'y avait qu'une seule annotation @Controller, alors ce composant aurait la répartition, la logique métier et l'accès à la base de données tout mélangé, donc du code sale !
Ce qui précède est un scénario très courant, il existe de nombreux autres cas d'utilisation pour expliquer pourquoi utiliser trois annotations.
12 votes
Étant un développeur avec une expérience chez Microsoft, je me souviens de la définition sémantique des services dans l'ancien framework MS SmartClientSoftwareFactory (maintenant un ancien framework complexe pour les applications de bureau distribuées). Cette définition (bien documentée par Rich Newman) a défini les services comme des objets réutilisables sans état, de préférence avec une portée singleton, utilisés pour effectuer des opérations de logique métier sur d'autres objets passés en tant qu'arguments. J'ai tendance à voir les services Spring de la même manière.
3 votes
Peu importe!! Peu importe ce qui fonctionne pour vous :) J'ai toujours détesté cela à propos de Spring qu'ils ont toujours tendance à définir des "règles" pour vous, qui n'ajoutent qu'une valeur triviale à votre application. Sans oublier que Spring vient avec une énorme pile de ses propres.
44 votes
@TriCore Sprting est un cadre, définir "règles" pour vous est son travail :)