Registrazione, programmazione orientata all’aspetto e iniezione delle dipendenze – Cercando di dare un senso a tutto

So che il logging è un caso di primo utilizzo per AOP. I wrapper di registrazione aggiuntivi sono inoltre esemplificati come casi in cui si desidera utilizzare la DI in modo che le classi non siano accoppiate con un’implementazione di registrazione specifica. Tuttavia, alcuni considerano la registrazione di wrapper come anti-pattern . In primo luogo, tale visualizzazione è dovuta al fatto che nella maggior parte dei casi il wrapper tende ad essere semplicistico e rimuove molte delle caratteristiche specifiche del framework di registrazione. Se implementi queste caratteristiche specifiche, perché non utilizzare direttamente il framework.

Sono a conoscenza della facciata Common.Logging che tenta di astrarre una buona quantità delle funzionalità di log4Net, EntLib, NLog per te. Tuttavia, anche qui abbiamo ancora una sorta di dipendenza su Common.Logging. Non in un modo di test di codice / unità per quanto riguarda le interfacce e simili, ma se il progetto muore (è passato più di un anno dall’ultima versione) o si desidera passare a un logger non supportato, ciò può causare problemi.

Detto questo, se la registrazione viene effettuata tramite AOP, è addirittura necessario utilizzare DI per la dipendenza dalla registrazione (ovvero perché non si fa riferimento direttamente a NLog)? Sì, la porzione di codice AOP sarebbe strettamente accoppiata, ma la logica delle classi che si desidera testare l’unità è priva di dipendenze di registrazione (almeno prima che avvenga la trama). È a questo punto che sono un po ‘perso (non ho ancora provato AOP). Dopo la tessitura, se non avessi usato DI per il codice AOP, avresti avuto problemi con l’unità test del metodo sotto test? Oppure si può testare un’unità senza tessere il codice AOP?

A meno che la registrazione non sia un requisito dell’utente del software, non sono sicuro di quanto sia utile verificare che la registrazione sia avvenuta con i mock. Penserei che la logica di business del metodo in esame è ciò che la maggior parte sarebbe interessata a testare. Infine, se si vuole usare TDD / BDD, non si dovrebbe usare DI per le dipendenze di logging nel codice AOP? O non si potrebbe semplicemente testare il lato AOP delle cose?

Come potete vedere, sto cercando di capire quale sia l’approccio più pratico per lo sviluppo di un’applicazione che utilizzerebbe sia AOP per problemi trasversali e DI per design / test. Poiché AOP è relativamente nuovo e la registrazione è l’esempio più comune, qual è l’approccio consigliato?

La registrazione non è un servizio, è una preoccupazione trasversale . In quanto tale, è meglio implementato con un decoratore . Tuttavia, l’aggiunta di molti Decorator solo per abilitare la registrazione di vari servizi diversi tende a violare DRY , nel qual caso è ansible quindi evolvere ulteriormente questi Decoratori in un singolo Interceptor.

Mentre è ansible utilizzare IL tessitura per implementare AOP, un’opzione migliore è utilizzare un contenitore DI che supporta l’intercettazione dynamic, in quanto è una soluzione molto più leggera.

Ciò consente di disaccoppiare completamente i servizi concreti dalla registrazione. In tal caso, direi che non vi è alcun motivo per racchiudere un particolare framework di registrazione, perché se si desidera modificare il framework di registrazione, è sufficiente modificare quel singolo Interceptor.

Ecco un esempio che parla di Decoratori e Interceptor per la strumentazione (molto simile al logging).

Se vuoi saperne di più su AOP e DI, puoi vedere online questo discorso che ho tenuto a GOTO Copenhagen 2010 .