Sono responsabile dell'aggiornamento di un prodotto software costituito da due componenti, il processo Controller e il processo dell'interfaccia utente. Il controller e l'interfaccia utente comunicano tramite messaggi XML. Inoltre, il Controller è costruito su una libreria condivisa che implementa un numero di flussi aziendali.
Per la raccolta dei messaggi per la comunicazione Controller-UI, qualcuno ha deciso di utilizzare la serializzazione e deserializzazione incorporate .NET e quindi ha creato tipi di classe annotati con attributi che controllano la serializzazione (XmlElement, XmlAttribute, ecc.) per ciascun messaggio, serializzandolo e deserializzare usando il serializzatore XML predefinito.
Per la prima coppia di controller, questo andava bene. Ma ora, mentre alcuni dei messaggi possono essere riutilizzati, l'altro no. Compiranno le funzioni simili ma sono strutturalmente incompatibili con le informazioni che abbiamo bisogno che contengano.
Poiché questa decisione è stata presa, siamo bloccati con tipi di dati che non sono in grado di modellare i dati di cui abbiamo bisogno e non possono essere modificati perché potrebbero rompere gli altri controller. Allo stesso tempo abbiamo bisogno delle sequenze di funzionalità e messaggistica implementate nella libreria condivisa.
Ho bisogno di una via d'uscita da questo enigma, uno che ha il più piccolo costo tecnico in relazione alla modifica degli altri controller, ho bisogno di una sorta di "polimorfismo strutturale" per questi tipi, dove il tipo è lo stesso ma la sua struttura interna diversa.
Forse questi messaggi possono essere cambiati in tipi di dati 'oggetto', ma in quel caso ... Ho bisogno di un modo per controllare dall'esterno della libreria condivisa il casting che viene creato all'interno della libreria condivisa.
Come mi avvicino a questo, non ho esperienza sufficiente per trovare un refactoring pulito per questo? Mi sento bloccato.
Stiamo usando .NET 4.5