Ancora su DGML…
Recuperando il mio post precedente, facciamo qualche esempio real world.
Immaginiamo la semplice e solita Console Application, senza alcuna modifica, cosi come è creata di default. Ecco cosa abbiamo, generando il diagramma delle dipendenze in base agli assemblies:
Salta immediatamente all’occhio come le dipendenze esterne siano organizzate, in questo caso sono solamente le tre importate in fase di creazione (Microsoft.VisualBasic.dll, System.dll e mscorlib.dll). Ma soprattutto, il contenuto delle DLL che viene effettivamente utilizzato dal nostro software (è evidente che di mscorlib non utilizziamo tutto, ma solamente una porzione).
Selezionando invece la generazione di un diagramma in base ai namespaces, il risultato è questo:
Sempre con la stessa applicazione di prima, ovviamente il grosso delle chiamate è all’esterno, ed in particolar modo da System.
Vi risparmio per ovvie ragioni il diagramma generato in base alle classi dell’applicativo.
Ma ora, qual’è il codice DGML che c’è dietro?
Purtroppo non è leggibilissimo, ho ridotto un po’ la dimensione del testo. Genera davvero tanto tanto codice che poi è customizzabile nei modi che abbiamo visto durante il primo post.
Ovviamente in caso di architetture più complesse, la visualizzazione grafica ci viene estremamente in aiuto nel caso in cui si debba mettere mano su qualcosa di non nostro, per delle modifiche pesanti, ad esempio.