Je travaillais avec Guice il y a quelques mois et maintenant, quand je reviens à cela, je trouve que je dois relire la documentation de Guice et des exemples pour comprendre ce que j'ai fait avec mon code.
Cependant, lorsque je regarde Aspectj, tout est trop intuitif. C'est une extension intuitive de la langue java. Je sens que je peux m'asseoir et écrire un code de Aspectj immédiatement.
Par conséquent, je suis tenté d'abandonner ma poursuite de Guice et d'aller avec Aspectj. Surtout le fait que le printemps génère du code de Aspectj.
Quelles caractéristiques de Guice y a-t-il au-dessus de LOPEJ qui devrait me décourager d'abandonner la Guice?
Pourquoi Google n'aurait-il pas de guice et d'utiliser AspectJ à la place?
Vice versa, quelles sont les caractéristiques de Aspectj qui m'encouragerait à abandonner Guice, outre la intuitive de celle-ci?
Si je peux être autorisé à "tisser" dans une question ici, qu'est-ce qui excluait la libération de la langue Java d'être fusionné avec AspectJ ou fournir des "aspects" similaires dans une future version de Java?
3 Réponses :
Selon moi, Aspectj et Guice font différentes choses.
Guice injecte des dépendances et Aspecj traite des préoccupations transversales.
Si vous utilisez le printemps, il y a moins de valeur à l'aide de Guice car il y a trop de chevauchement, puis la symbiose du printemps / aspect est une solution convaincante.
i PersonQlly comme Guice mieux pour les projets autres que le printemps en raison de son poids plus léger.
Comme Peter dit, Guice et Aspecj sont des choses totalement différentes. Guice fait une injection de dépendance, sauvegarde des terrains d'écriture en usine tout en faisant du code flexible et facile à tester et à ajouter des objets utiles comme les champs. Il arrive également à permettre une manière très simple et facile de faire de l'AOP via une interception de la méthode (avec une configuration programmatique de quelles méthodes sont interceptées, plutôt qu'une DSL). C'est effectivement juste un autre bonus qu'il fournit et non son objectif essentiel du tout.
En ce qui concerne pourquoi Aspecj n'est pas fusionné dans Java ... Je ne me sens pas comme beaucoup de gens voudront que cela se produise. AOP est puissant, mais de manière dangereuse. Bien que ce soit certainement génial pour certaines utilisations et simplifie beaucoup le code dans ces cas, s'il était surlu, il pouvait en faire beaucoup plus difficile de comprendre ce qui se passe dans un programme.
Spring est construit sur une injection de dépendance et une programmation orientée forme.
Guice est un moteur d'injection de dépendance.
asphapj est un moteur orienté vers l'aspect.
Voir la différence? Guice et Aspecj seraient complémentaires; Le printemps a déjà les deux.
Il convient de mentionner que le ressort prend en charge son propre AOP à base d'intercepteur, qui ne nécessite pas de manipulation de code d'octet, en plus de AspectJ.
Guice comprend son propre support AOP: code.google.com/p/google-Guice / wiki / aop
Ne savait pas ça; Je vous remercie. Ressemble à l'intercepteur de la méthode du ressort. Cela faisait-il partie de la Guice originale de Bob Lee ou ajouté après la première version?
Abstractmodule.bindinterceptor fait partie de Guice 1.0.
J'ai toujours exactement avec le même sentiment. Pourquoi un cadre d'injection de dépendance si j'ai l'aspectj?