Je sais que cette question a été posée auparavant, mais c'était il y a un an et demi, même si je pensais que ce serait peut-être le temps d'une réinitialisation. J'ai aussi reconnu que cela pourrait être considéré comme subjectif, mais je suppose qu'il y a des raisons objectives pour / contre l'AOP.
Je serais intéressé par Je vois un AOP comme un paradigme très puissant qui peut faciliter de nombreuses tâches de développement. Mais quand il s'agit d'utiliser un AOP dans des projets du monde réel, j'ai fait l'expérience que de nombreux décideurs sont à peine ouverts. Comment avez-vous réussi à introduire un AOP dans vos projets?
Question précédemment posée d'août 2008: Utilisez AOP (programmation orientée forme) dans le logiciel de production?
3 Réponses :
Nous n'utilisons pas 100% 100% en soi, mais oui, nous utilisons chaque fois que nous nous sentons appropriés (surtout le ressort AOP; c'est si joliment intégré à la framework de printemps)
Comment avez-vous réussi à introduire un AOP dans vos projets?
Eh bien, séparez les préoccupations transversales, par exemple. appels de méthode de traçage. Dans le ressort AOP, vous pouvez définir un aspect (un comportement d'exécution) qui sera appliqué à une section "hooked" code. Avec "Hooked", je veux dire, vous devriez être capable de regrouper toutes les méthodes où vous avez besoin de ce comportement sous un parapluie commun. Au moment de l'exécution, ce code parapluie obtiendra un nouveau comportement tel que défini par votre aspect.
Nos gestionnaires écoutent leur équipe d'architecture.
Nous leur dire que l'AOP est la seule solution pour implémenter des fonctionnalités croisées concernent:
Il est vrai que notre projet est de 20 développeurs et a duré plusieurs années, donc il y a une masse énorme de code. Il est la seule solution.
Je crois que la clé est de l'utiliser uniquement pour des préoccupations transversales. Si vous pouvez coder en utilisant le code régulier, faites-le. Mais si elle est trop grand, alors AOP est attrayante et justifiée. A défaut d'AOP limite conduirait à des centaines de petits AOP codes, ce serait très difficile à comprendre.
Et oui, notre logiciel est-logiciel de production. Des centaines de cliniques dépendent!
Spring AOP alors que Pekit dit est facile à introduire si vous utilisez déjà un cadre de ressort dans votre projet.
J'ai d'abord ajouté Aspectj pour notre projet d'outils qui n'est utilisé que en interne et jamais libéré aux clients. Cela a aidé à la fois l'équipe de développement et la gestion de gagner la confiance sur l'outil et d'avoir une idée claire sur ce qu'elle peut faire pour eux.