table des matières
La différence entre l'AOP d'AspectJ et Spring
Troisièmement, le comportement de communication des affaires
Quatre, transaction déclarative Spring et transaction programmatique
Cinq, la différence entre @Autowire et @Resource
1. CIO et DI
IOC et DI sont un concept, l'injection de dépendances, c'est-à-dire que lorsqu'un rôle a besoin de l'aide d'un autre rôle, dans le processus de programmation traditionnel, l'appelant crée généralement une instance de l'appelé. Mais au printemps, le travail de création de l'appelé n'est plus effectué par l'appelant, en créant (lorsque le conteneur de ressort démarre, spring initialisera tous les beans que vous avez configurés dans le fichier de configuration, puis lorsque vous devez appeler, attribuez-les simplement beans qui ont été initialisés aux classes dont vous avez besoin pour appeler ces beans) Le travail de l'appelé est effectué par spring, puis injecté dans l'appelant, c'est donc appelé inversion de contrôle.
Spring gère les objets de manière dynamique et flexible.Il existe trois méthodes d' injection, d'injection de méthode de construction, d'injection de setter et d' injection basée sur des annotations .
L'avantage de l'injection de construction: l'ordre des dépendances peut être déterminé dans le constructeur.
Avantages du réglage de l'injection: intuitif et naturel
Spring fournit de nombreuses implémentations de conteneurs IOC, tels que XmlBeanFactory et ClasspathXmlApplicationContext. XmlBeanFactory est l'implémentation du conteneur ioc le plus basique. Ce conteneur IOC peut lire le BeanDefinition défini dans le fichier XML (la description du bean dans le fichier XML)
L'initialisation du conteneur IOC comprend les trois processus de base de l'emplacement, du chargement et de l'enregistrement des ressources BeanDefinition.
Deux, AOP
On peut dire que l'AOP complète et perfectionne la POO. La POO introduit des concepts tels que l'encapsulation, l'héritage et le polymorphisme pour établir une hiérarchie d'objets afin de simuler une collection de comportements publics. Lorsque nous devons introduire des comportements publics pour des objets dispersés, la POO est impuissante. En d'autres termes, la POO vous permet de définir une relation de haut en bas, mais elle ne convient pas pour définir une relation de gauche à droite. Par exemple, la fonction de journalisation. Le code de journal est souvent distribué horizontalement dans tous les niveaux d'objet et n'a rien à voir avec les fonctions de base des objets auxquels il est distribué. Dans la conception POO, cela conduit à beaucoup de duplication de code, ce qui n'est pas propice à la réutilisation de divers modules. (Extrayez le code répété de la même logique horizontalement et utilisez la technologie de proxy dynamique pour intégrer ces codes répétés dans la méthode d'objet cible pour obtenir la même fonction que l'original. De cette manière, nous ne nous soucions que du code métier lors de l'écriture de l'entreprise , et ne vous souciez pas du code qui n'a rien à voir avec l'entreprise)
Spring AOP utilise le proxy dynamique JDK par défaut . Si la classe proxy n'a pas d'interface, elle utilisera le proxy CGLib .
S'il s'agit d'un seul cas , nous ferions mieux d'utiliser le proxy CGLib , s'il s'agit de plusieurs cas , nous ferions mieux d'utiliser le proxy JDK.
Raison: les performances de JDK lors de la création d'objets proxy sont supérieures à celles du proxy CGLib, tandis que les performances de génération d'objets proxy sont inférieures à celles de CGLib.
①Spring aop xml méthode.
<aop:config>
<aop:pointcut expression="execution(* com.aop.impl.xml.ArithmeticCalculator.*(..))" id="pointcut"/>
<aop:aspect ref="logging" order="1">
<aop:before method="beforeMethod" pointcut-ref="pointcut"/>
<aop:after method="afterMethod" pointcut-ref="pointcut"/>
<aop:after-returning method="afterReturnning" returning="result" pointcut-ref="pointcut"/>
<aop:after-throwing method="afterThrowing" throwing="ex" pointcut-ref="pointcut"/>
<!-- <aop:around method="aroundMethod" pointcut-ref="pointcut"/> -->
</aop:aspect>
<aop:aspect ref="validation" order="2">
<aop:before method="validation" pointcut-ref="pointcut"/>
</aop:aspect>
</aop:config>
②Méthode d'annotation Spring aop.
La différence entre l'AOP d'AspectJ et Spring
AspectJ au moment de la compilation pour améliorer l'objet cible (lors de la compilation de l'Aspect tissé dans le code d'octet Java, le temps d'exécution est écoulé après les améliorations de l'objet AOP), les proxys dynamiques Spring AOP est une amélioration dynamique à chaque exécution, Générer des objets proxy AOP, le La différence est que le moment de la génération des objets proxy AOP est différent. Relativement parlant, la méthode proxy statique d'AspectJ a de meilleures performances, mais AspectJ nécessite un compilateur spécifique pour le traitement, tandis que Spring AOP ne nécessite pas de traitement spécifique du compilateur.
Troisièmement, le comportement de communication des affaires
ServiceA{
methodA(){
for(int i=0;i<=1i++){
serviceB.methodB();
}
}
}
ServiceB(){
@Transcational
methodB(){
}
}
Niveau d'isolement de transaction de la méthodeB |
Il y a une transaction dans la méthode A () de ServiceA |
Aucune transaction dans methodA () of ServiceA |
la description |
Propagation OBLIGATOIRE |
Exécuter dans la transaction de methodA |
Démarrez une nouvelle transaction pour methodA, mais exécutez la transaction de methodB | Si l'appelant a une transaction en cours d'exécution, la méthode actuelle s'exécute dans cette transaction, sinon une nouvelle transaction est redémarrée pour l'appelant et s'exécute dans la transaction de la méthode appelée. |
Propagation.REQUIRES_NEW |
Ouvrez une nouvelle transaction pour methodA, mais exécutez la transaction de methodB |
Ouvrez une nouvelle transaction pour methodA, mais exécutez la transaction de methodB |
Dans tous les cas, une nouvelle transaction est ouverte pour l'appelant, mais elle s'exécute dans la transaction de l'appelé. Si une transaction est en cours d'exécution, elle doit d'abord être suspendue. |
Propagation. |
Exécuter dans la transaction de methodA |
Exécuter dans la transaction de methodB |
Si l'appelant a une transaction en cours d'exécution, la méthode actuelle s'exécutera dans cette transaction, sinon il ne pourra pas s'exécuter dans la transaction de l'appelant (s'exécute dans la transaction de l'appelé) |
Propagation OBLIGATOIRE:
Propagation.REQUIRES_NEW:
Quatre, transaction déclarative Spring et transaction programmatique
1. Les transactions programmatiques utilisent TransactionTemplate ou utilisent directement le PlatformTransactionManager sous-jacent, et vous devez démarrer et valider manuellement les transactions. Pour la gestion des transactions par programme, Spring recommande d'utiliser TransactionTemplate.
2. Les transactions déclaratives sont basées sur AOP. Son essence est d'intercepter avant et après la méthode, puis de créer ou d'ajouter une transaction avant le démarrage de la méthode cible, et de soumettre ou d'annuler la transaction en fonction de l'exécution après l'exécution de la méthode cible. Le plus grand avantage des transactions déclaratives est qu'il n'est pas nécessaire de gérer les transactions via la programmation, il n'est donc pas nécessaire de doper le code de gestion des transactions dans le code de logique métier, il suffit de faire la déclaration de règle de transaction appropriée dans le fichier de configuration (ou via @Transactional Annotation), vous pouvez appliquer des règles de transaction à la logique métier. Deux voies:
①Fichier de configuration XML basé sur les espaces de noms tx et aop
<!-- 配置事务属性 -->
<tx:advice id="txAdvice" transaction-manager="transactionManager">
<tx:attributes>
<tx:method name="purchase" propagation="REQUIRES_NEW"/><!-- 指定重开事务的方法 -->
<tx:method name="*"/>
</tx:attributes>
</tx:advice>
<!-- 配置事务切入点,以及把事务切入点和事务属性关联起来 -->
<aop:config>
<aop:pointcut expression="execution(* tx.xml.service.*.*(..))" id="txPointCut"/>
<aop:advisor advice-ref="txAdvice" pointcut-ref="txPointCut"/>
</aop:config>
② Utilisez l'annotation @Transactional
<!-- 配置事务管理器 -->
<bean id="transactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"></property>
</bean>
<!-- 启动事务注解 -->
<tx:annotation-driven transaction-manager="transactionManager"/>
Cinq, la différence entre @Autowire et @Resource
@Autowire bytype pour la correspondance, s'il existe plusieurs types de correspondance, utilisez @Qualifiter pour spécifier le nom du bean injecté (aucune erreur ne sera signalée)
Le nom @Resource peut être spécifié par l'attribut name. Si l'attribut name n'est pas spécifié, lorsque l'annotation est écrite sur le champ, le nom du champ est pris par défaut et recherché par nom. Si l'annotation est écrite sur la méthode setter , le nom d'attribut est utilisé par défaut pour l'assembly. Lorsqu'aucun bean correspondant au nom n'est trouvé, l'assemblage est effectué en fonction du type. Mais il faut noter que si l'attribut name est spécifié, il ne sera assemblé qu'en fonction du nom.