È possibile analizzare la superficie dell'API di un set di librerie di classi per determinare automaticamente le dipendenze tra gli assembly?

2

Sono sicuro che siamo stati tutti nella situazione in cui abbiamo ereditato codice che era "eccessivamente pubblico", che diventa obsoleto o che deve essere sottoposto a refactoring. In queste situazioni, è facile passare molti giorni analizzando la superficie dell'API per vedere dove vengono consumati i metodi o le classi; con il runtime .Net, sembra logico che dovrebbe essere relativamente banale mappare queste dipendenze tra gli assembly, ma sembra che non ci siano strumenti là fuori che lo facciano già?

Ad esempio, suggeriamo di avere una libreria di classi CRM che incapsula l'interfaccia con tutti i dati del cliente; non è irragionevole che un'applicazione di citazioni possa fare affidamento su questo, ma sembra non banale identificare su quali bit . Un approccio ingenuo sarebbe dire che le interfacce pubbliche (tipi, ecc.) Sono la superficie dell'API, ma potrebbe essere il caso che alcune di queste interfacce siano solo pubbliche per il consumo in un particolare caso d'uso, che potrebbe diventare non valido.

È possibile determinare e mappare automaticamente le dipendenze tra gli assembly per un determinato set di assiemi?

    
posta Rowland Shaw 28.02.2012 - 15:53
fonte

2 risposte

2

Strumenti di analisi statica come nDepend fai questo.

Ha delle viste che ti dicono quali tipi sono usati dove e quanto spesso, le dipendenze circolari riconosciute e altro ancora.

    
risposta data 28.02.2012 - 16:02
fonte
0

Sono sicuro che potresti identificare alcune delle dipendenze, ma non tutte. Ad esempio, che dire di una chiamata al servizio web generata dinamicamente o letta da una risorsa?

    
risposta data 28.02.2012 - 16:55
fonte

Leggi altre domande sui tag