Il valore sottostante della programmazione orientata all'aspetto [chiuso]

AOP è vantaggioso per il progetto se hai diversi membri del tuo team in possesso di una vasta esperienza con AOP. Altrimenti otterrete una miscela molto strana di codice procedurale AOP + OOP +. La mia raccomandazione è di fare affidamento su AOP per la registrazione e / o la gestione degli errori per dimostrare al team che è importante e funziona come previsto. Inoltre, può insegnare loro le tecniche appropriate per scrivere i livelli che sono importanti, ad esempio se eseguono errori durante la fase di test, l'applicazione esploderà, che è ciò che vorresti che accadesse.

Dal mio punto di vista su AOP, dovrebbe non richiedere diversi membri del team con una vasta esperienza. Se usato correttamente (cioè, non sovrautilizzare) e correttamente introdotto nel team, il guadagno previsto nella leggibilità del codice e nella produttività dovrebbe essere ovvio per tutti.

Dovresti trovare un modo per presentare un compendio degli aspetti che fornisci, in modo che ogni membro del team possa trovare facilmente informazioni riguardanti gli aspetti e le loro funzionalità.

Anche se non l'ho mai usato, trovo attraente l'idea di memorizzare nella cache gli aspetti. Ci sono molti post di blog su questo, e penso che ci sia un esempio nella distribuzione di postsharp.