LocalStone
Messages postés514Date d'inscriptionmercredi 19 mars 2003StatutMembreDernière intervention 1 mars 2009
-
22 févr. 2009 à 18:40
cs_stailer
Messages postés507Date d'inscriptionjeudi 28 mars 2002StatutMembreDernière intervention13 mai 2009
-
1 mars 2009 à 10:53
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
cs_stailer
Messages postés507Date d'inscriptionjeudi 28 mars 2002StatutMembreDernière intervention13 mai 20091 1 mars 2009 à 10:53
Très bonne source... Mais pour moi, trop de séparation, tue la séparation. Probablement que sur un projet extrêmement dense l'AOP est utile, mais la, si je veux modifier le fichier attaché à ma classe je vais devoir aussi modifier ma classe. Je pense qu'il va y avoir une certaine perte de temps et une multiplication des fichiers.
C'est un avis personnel.
Pour finir, et à contre-courant : je n'ai aucun mal à faire du PHP alors que je m'éclate en C# et en Java. Ca n'a rien à voir, il a de nombreuses qualités que C# et Java n'ont pas et inversement.. Mais surtout : L'AUTOCOMPLETION EXISTE ! Elle fonctionne parfaitement avec Eclipse ou Netbeans ; )
Essayez les, vous les adopterez (sans parler du reste : SVN, multi-projets, accès direct aux objets, méthodes avec CTRL+clic et j'en passe....).
LocalStone
Messages postés514Date d'inscriptionmercredi 19 mars 2003StatutMembreDernière intervention 1 mars 2009 1 mars 2009 à 00:26
@Coucou747: T'as pas idée du mal que j'ai eu pour revenir au PHP. Et le pire, c'est l'inverse : j'ajoute des [function] à toutes les méthodes et je préfixe toutes les variables alors que ça ne sert pas à grand chose en Java.
Et concernant l'intérêt de l'AOP ... Détrompe-toi ! C'est énormément utilisé ! C'est avec Hibernate (en Java) que j'ai compris à quel point c'était puissant (http://www.hibernate.org/) et donc indispensable :P.
@aKheNathOn: J'ai pas très bien compris la première question. Par contre, je peux te donner mon avis pour la seconde (je suis loin d'être un expert). Déjà, tu fais un aspect pour la journalisation, qui ne doit pas être bien sorcier. En gros, tu mets des advices autour de toutes les méthodes fonctionnelles qui t'intéressent. Ensuite, pour la partie transaction, tu fais un te mets autour de la méthode qui te permet de faire un retrait. Si aucune exception n'est lancée, alors ça veut dire que le mec à le droit de le faire, donc tu peux faire la transaction. Sinon, tu attrapes l'exception, tu ne fais pas la transaction et tu relances la transaction pour en faire profiter le reste de l'application.
Et tu as raison, je ne gère les pas les pointcuts avant et après une méthodes. Je ne me suis occupé que du pointcut "around", parce que c'est le plus puissant (et aussi parce que j'avais la flemme de faire le reste).
Il manque également deux choses importantes pour que l'on puisse utiliser mon module en pratique :
1. ce que j'appellerais un contexte d'aspect, qui permet de stocker des variables pour un aspect (des champs voire des méthodes que l'aspect peut appeler, sachant que ce context doit évoluer indépendamment pour chaque instance proxifiée par l'aspect) ;
2. des annotations, à la manière du Java, à placer autour de la déclaration des classes et des méthodes, utilisables par les aspects.
Voili voilou ! Merci pour vos commentaires en tout cas !
L'exemple partant sur de l'ORM est sympa même si c'est pas l'utilisation la plus optimisée, mais on y voit bien le principe.
En terme de POA je part du principe que l'aspect est persistance.xml et que le joinpoint est aspect.php.
Petite question : étant donné que le principe est de cloisonner la logique métier en enlevant les contraintes inter-modulaires reposant sur par exemple sur des modules techniques tels que du log ou bien du requettage, dans ton point-cut pk et comment tu utilises une base de données (c'est créer des dépendances non ?) ?
Autre question, ton advice, on dirais qu'il ne gère que le mode d'exécution pendant (pas de mode avant appel et après appel).
Dernière question du type comment faire :
J'ai un module de transaction bancaire, un autre de log et un autre de transaction sql.
Je dois faire un action de retrait : vérifier le compte de l'utilisateur, si celui-ci à le droit de retirer la somme, je le fais. Dans les deux cas je stock un log de l'action et du résultat, ainsi que dans le cas d'un retrait, met à jour le solde du client dans la partie SQL.
Quels seraient les advices, et à quoi pourrait ressembler le join point ?
Merci d'avance pour tes réponses.
Bonne prog et à+,
Akh
coucou747
Messages postés12303Date d'inscriptionmardi 10 février 2004StatutMembreDernière intervention30 juillet 201244 25 févr. 2009 à 09:00
OMG
c'est tres interessant.
t'as pas eu du mal a revennir vers php apres avoir fait du java ?
apres avoir fait du java, je lance kate pour faire du php, je tape $this-> et controle space, et j'attends betement que kate me liste les methodes de l'objet courrant, chose qu'il ne sait evidement pas faire :(
c'est une belle utilisation de la reflection, meme si je doute que ca soit tres utile en pratique.
LocalStone
Messages postés514Date d'inscriptionmercredi 19 mars 2003StatutMembreDernière intervention 1 mars 2009 22 févr. 2009 à 18:40
1 mars 2009 à 10:53
C'est un avis personnel.
Pour finir, et à contre-courant : je n'ai aucun mal à faire du PHP alors que je m'éclate en C# et en Java. Ca n'a rien à voir, il a de nombreuses qualités que C# et Java n'ont pas et inversement.. Mais surtout : L'AUTOCOMPLETION EXISTE ! Elle fonctionne parfaitement avec Eclipse ou Netbeans ; )
Essayez les, vous les adopterez (sans parler du reste : SVN, multi-projets, accès direct aux objets, méthodes avec CTRL+clic et j'en passe....).
1 mars 2009 à 00:26
Et concernant l'intérêt de l'AOP ... Détrompe-toi ! C'est énormément utilisé ! C'est avec Hibernate (en Java) que j'ai compris à quel point c'était puissant (http://www.hibernate.org/) et donc indispensable :P.
@aKheNathOn: J'ai pas très bien compris la première question. Par contre, je peux te donner mon avis pour la seconde (je suis loin d'être un expert). Déjà, tu fais un aspect pour la journalisation, qui ne doit pas être bien sorcier. En gros, tu mets des advices autour de toutes les méthodes fonctionnelles qui t'intéressent. Ensuite, pour la partie transaction, tu fais un te mets autour de la méthode qui te permet de faire un retrait. Si aucune exception n'est lancée, alors ça veut dire que le mec à le droit de le faire, donc tu peux faire la transaction. Sinon, tu attrapes l'exception, tu ne fais pas la transaction et tu relances la transaction pour en faire profiter le reste de l'application.
Et tu as raison, je ne gère les pas les pointcuts avant et après une méthodes. Je ne me suis occupé que du pointcut "around", parce que c'est le plus puissant (et aussi parce que j'avais la flemme de faire le reste).
Il manque également deux choses importantes pour que l'on puisse utiliser mon module en pratique :
1. ce que j'appellerais un contexte d'aspect, qui permet de stocker des variables pour un aspect (des champs voire des méthodes que l'aspect peut appeler, sachant que ce context doit évoluer indépendamment pour chaque instance proxifiée par l'aspect) ;
2. des annotations, à la manière du Java, à placer autour de la déclaration des classes et des méthodes, utilisables par les aspects.
Voili voilou ! Merci pour vos commentaires en tout cas !
25 févr. 2009 à 17:22
L'exemple partant sur de l'ORM est sympa même si c'est pas l'utilisation la plus optimisée, mais on y voit bien le principe.
En terme de POA je part du principe que l'aspect est persistance.xml et que le joinpoint est aspect.php.
Petite question : étant donné que le principe est de cloisonner la logique métier en enlevant les contraintes inter-modulaires reposant sur par exemple sur des modules techniques tels que du log ou bien du requettage, dans ton point-cut pk et comment tu utilises une base de données (c'est créer des dépendances non ?) ?
Autre question, ton advice, on dirais qu'il ne gère que le mode d'exécution pendant (pas de mode avant appel et après appel).
Dernière question du type comment faire :
J'ai un module de transaction bancaire, un autre de log et un autre de transaction sql.
Je dois faire un action de retrait : vérifier le compte de l'utilisateur, si celui-ci à le droit de retirer la somme, je le fais. Dans les deux cas je stock un log de l'action et du résultat, ainsi que dans le cas d'un retrait, met à jour le solde du client dans la partie SQL.
Quels seraient les advices, et à quoi pourrait ressembler le join point ?
Merci d'avance pour tes réponses.
Bonne prog et à+,
Akh
25 févr. 2009 à 09:00
c'est tres interessant.
t'as pas eu du mal a revennir vers php apres avoir fait du java ?
apres avoir fait du java, je lance kate pour faire du php, je tape $this-> et controle space, et j'attends betement que kate me liste les methodes de l'objet courrant, chose qu'il ne sait evidement pas faire :(
c'est une belle utilisation de la reflection, meme si je doute que ca soit tres utile en pratique.
22 févr. 2009 à 18:40