Il refactoring ha cercato di sostituire i tipi di dati condivisi nel componente .NET

2

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

    
posta Rire1979 11.04.2014 - 08:23
fonte

2 risposte

3

Il Serializer XML predefinito è abbastanza flessibile. Ignora (per impostazione predefinita) ciò che non sa (sono informazioni sul file / flusso xml per il quale non esiste alcuna variabile membro), e ciò che sa e non è presente (nel file / flusso xml), fornisce i valori predefiniti . Quindi, un modo molto sporco è solo aggiungere ciò di cui hai bisogno dove ti serve. Funzionerà. Non sarà carino.

Se vuoi avere un po 'più di controllo, puoi implementare IXmlSerializable e sovrascrivere i metodi WriteXml e ReadXml per scrivere o leggere solo ciò che è necessario da / per il file / flusso xml

    
risposta data 11.04.2014 - 10:05
fonte
1

I need a way out of this conundrum, one that has the smallest technical cost in relation to changing the other controllers, I need a sort of "structural polymorphism" for these types, where the type is the same but its internal structure different.

Intendi ereditarietà di base? Non sono sicuro di vedere il problema qui. Se si dispone di un insieme comune di funzionalità, definire un'interfaccia (o una classe di base astratta) per tale funzionalità. Se disponi di diverse implementazioni di tale funzionalità (inclusi i membri serializzati internamente), esegui semplicemente diverse implementazioni di tale interfaccia.

Probabilmente dovrai usare KnownType o altri attributi per assicurarti che il serializzatore sia a conoscenza dei tipi di implementazione. E potresti scoprire che l'utilizzo di un supporto di serializzazione diverso (json, binary) può semplificarti la vita. Ma da un approccio progettuale, questo sembra semplice.

    
risposta data 13.04.2014 - 18:58
fonte