xml serializzazione e deserializzazione situazione complessa

2

Sto considerando di passare xml avanti e indietro per i messaggi di errore, ma ogni errore ha scenari diversi.

una situazione a portata di mano sta passando il confronto del testo diffuso mentre altre sono semplici come passare un messaggio di testo.

Che tipo di strategia di serializzazione / deserializzazione potrei usare per uno scenario del genere?

Il problema principale con uno scenario come questo è che l'oggetto è diverso da caso a caso e deve esserci un meccanismo per identificare il tipo che è.

Serializzare xml è piuttosto semplice:

Fin dall'inizio mi vengono in mente tre idee sciatte:

  1. Crea una super classe che contenga ogni possibilità di contenuto tipi.
  2. Crea un meccanismo per leggere prima l'xml da identificare cosa c'è dentro.
  3. Utilizzare l'opzione 2 e convertire il corpo interno xml in un oggetto.

Un approccio più elegante sarebbe quello di implementare una sorta di modello di azione, in cui, una volta identificato l'oggetto, è possibile creare l'azione appropriata da portare con sé.

Alcune idee sono costituite dal pattern Action / Executor o IoC:

Ecco un'idea di esempio di esempio che corre parallela a ciò che sto pensando:

Non per la persistenza dei dati ma per la gestione degli errori da parte del client: Il client decide come gestire l'errore una volta ricevuto basato sull'azione da una libreria di base che si svolge dopo la deserializzazione.

il mio formato xml considerato sarebbe qualcosa del tipo:

errore diff:

<errorMessage>
<header>The header is not correct</header>
<body>

<diffErrorArray>
<diffItem message="NoChange">
<customMessage>Correct</customMessage>
<source>HeaderColumn1</source>
<destination>HeaderColumn1</destination>
</diffItem>

<diffItem message="Replace">
<customMessage>Changed</customMessage>
<source>HeaderColumn1</source>
<destination>Header_Column_1</destination>
</diffItem>

<diffItem message="AddDestination">
<customMessage>Unknown</customMessage>
<source></source>
<destination>Header_Column_1</destination>
</diffItem>

<diffItem message="DeleteSource">
<customMessage>Missing</customMessage>
<source>HeaderColumn2</source>
<destination></destination>
</diffItem>

</diffErrorArray>

</body>
</errorMessage>

errore stringa:

<errorMessage>
<header>Bad news</header>
<body>
<stringErrorMessage>Something really bad happened.</stringErrorMessage>
<body>
</errorMessage>
    
posta Chris 18.03.2014 - 20:47
fonte

1 risposta

2

Deserializzazione Xml - almeno in caso di C # (non ti stai riferendo direttamente ad essa, ma i tuoi link indicano che è la tua lingua preferita) - ha il riconoscimento del tipo integrato. Perché non farne uso?

Vedi link per maggiori dettagli .

1: Make some super class that contains every possibility of contained types.

Come dimostrato nella domanda che ho collegato sopra, basta creare una classe base comune per gli oggetti errorMessage . Quindi devi utilizzare XmlInclude .

Quindi la super classe dovrebbe solo "contenere ogni possibilità" nel senso di sapere su tutti i suoi sottotipi (ma non i dettagli di implementazione). È ancora tutto bello e pulito in termini di OOP.

Nota che se ritieni che la serializzazione .NET sia troppo limitante, esistono sempre alternative più sofisticate come SharpSerializer - più adatto per scenari polimorfici.

Ancora una volta, questo non è un suggerimento agnostico per la lingua, ma se hai usato un altro linguaggio di programmazione, il consiglio rimane valido: puoi cercare una buona libreria open-source.

2: Make some mechanism for reading the xml first to identify what's in it.

Potresti anche usare il reflection e recuperare il tipo in fase di esecuzione (come suggerito da Kirtan) con il nome dell'elemento root o con qualche attributo dell'elemento root.

Un'altra opzione potrebbe essere quella di creare o generare schemi XSD per gli elementi errorMessage , quindi utilizzare questi schemi per convalidare i messaggi in arrivo, stabilendo così la loro "identità di tipo".

Un vantaggio di questo è certamente una soluzione un po 'più fastidiosa è che se l'xml in entrata fosse in qualche modo rotto, la convalida xsd potrebbe dirti esattamente dove e perché (ad esempio un elemento non riconosciuto e non riconosciuto), non devi gestirlo "manualmente".

Poi c'è una digitazione dinamica e un altro interessante approccio:

link

A more elegant approach would be to implement some kind of Action pattern, where, once the object was identified you could create the proper action to take with it.

Questo è ciò che accade dopo aver deserializzato il messaggio, vero?

Riguardo a ciò, non penso che si possano fornire suggerimenti superiori a quelli che hai già trovato in questo thread: link

Spero che questo ti dia qualche ispirazione. In caso contrario, il principio che seguo è: quando è terribilmente difficile risolvere un problema, molto probabilmente il problema in sé è mal posto fin dall'inizio. Quindi se sei bloccato, forse è ora di fare un passo indietro e riprogettare. Non conosco un contesto più ampio, quindi non ho modo di sapere quanto sia possibile nel tuo caso.

    
risposta data 18.03.2014 - 23:06
fonte

Leggi altre domande sui tag