DataContractSerializer: perché non rimuovere membri?

Question

leggevo Microsoft di Best Practices: Data Contract Versioning, e affermare:

Non rimuovere componenti di dati nelle versioni successive, anche se il IsRequired struttura è stata lasciata al suo proprietà predefinita di falso nelle versioni precedenti.

Qualcuno può suggerire un motivo per questo? Non elaborano. Dal momento che dicono che va bene aggiungere membri di dati in una versione successiva, sembra che la rimozione sia soddisfacente - in effetti, la versione precedente la vedrebbe come un add.

La differenza, suppongo, è che si supponga di aggiungere nuovi membri alla fine (utilizzando la proprietà Order in DataMemberAttribute), mentre la proprietà rimossa probabilmente non sarà alla fine. Ma dicono anche che i membri mancanti saranno lasciati al loro valore predefinito durante il caricamento, quindi è chiaro che i membri mancanti sono OK.

Cosa mi manca? Quali problemi di versione-interoperabilità dovrei causare (compatibilità diretta e retrocompatibilità) se avessi reso obsoleta una funzionalità del mio prodotto e rimosso la proprietà [DataMember] che ne deriva?

Inoltre, se avessi deciso di non essere interessato alla compatibilità diretta (ad esempio, se non fossi preoccupato per le versioni precedenti che aprono i file più recenti), potrebbero ancora verificarsi tali problemi?

Answer 1

Semplicemente perché i consumatori di servizi esterni possono fornire/utilizzare tali dati (sono stati creati prima di rimuovere alcuni membri). Nel caso in cui sia stata modificata la firma del metodo di servizio, DataContractSerializer non sarà più in grado di riconoscere DataContract, a causa di membri di dati sconosciuti.

Quindi, se i vostri consumatori di servizi sono tutti noti, si può facilmente manipolare i membri di dati a proprio arbitrio, purché si:

• Non rompere i consumatori o
• correttamente li informano del cambiamento

Answer 2

Un problema è che anche se non si interrompe durante la serializzazione/deserializzazione, è possibile che si stiano buttando via dati, ovvero che non è possibile tornare indietro correttamente al chiamante. vale a dire data la semplice metodo:

public SomeType Echo(SomeType obj) { 
    return obj; 
} 

Se il chiamante si sta passando il vecchio oggetto con la proprietà in più, si potrebbe desiderare quel valore indietro. È possibile abilitare questo (separatamente) con l'API extension data, ma francamente le persone raramente si preoccupano di questo.