Come migrare un framework di serializzazione XML in Java in un sistema strettamente accoppiato?

1

Lavoro per un'azienda che utilizza XML per archiviare un gruppo di classi Java serializzate. Il framework che usiamo è Apache Betwixt (abbandono nel 2008) ed è un tipo di dolore da mantenere ed estendere ( sembrava una buona scelta nel corso della giornata).

Crash course in Betwixt insieme al problema dettagliato:

  • Supporta solo getter e setter pubblici, devono essere presenti sia getter che setter
  • Non supporta gli adattatori di tipo JAXB
  • L'XML si evolve con gli oggetti Java, risultando in metodi ridondanti nelle nostre classi

Il nostro elenco di classi serializzabili xml ha superato i 150, e il codebase può diventare molto confuso quando vengono apportate modifiche alle definizioni. Poiché l'XML è vincolato a getter e setter Java, possiamo solo migrare XML mantenendo le vecchie proprietà nelle definizioni di classe.

Ora Dai un'occhiata a questa modifica:

public class ThingWithText {       
  private String text;

  public String getText() {
     return text;
  }

  public void setText(String text) {
     this.text = text;
  }
}

L'XML risultante assomiglia a:

<thingWithText>
    <text>Whatever</text>
</thingWithText>

Ora considera una modifica nel modello per aggiungere più locale a ThingWithText :

public class ThingWithText {
   private List<TextWithLanguage> texts = new LinkedList<TextWithLanguage>();

   // Getter must be here so the framework recognizes the property. 
   public String getText() {
      return null;
   }

   // Has to be here so it can be serialized
   public void setText(String text) {
      this.texts.add(new TextWithLanguage(text));
   }

   public List<TextWithLanguage> getTexts() {
      return texts;
   }

   public void addText(TextWithLanguage text) {
      texts.add(text);
   }
}

public class TextWithLanguage {
   private Locale locale = // omitted;
   private String text;

   public TextWithLanguage(String text) {
      this.text = text;
   }

   // Getter and setter omitted
}

L'XML ora assomiglia a:

<thingWithText>
    <texts>
        <text locale="en">Whatever</text>
    </texts>
</thingWithText>

Ora l'XML non è brutto o altro, ma lascia comunque la classe ThingWithText con diversi problemi:

  • Un setter per un campo non esistente
  • Un getter che restituisce sempre null, può causare eccezioni perché la roba è ancora compilata

Le mie domande vanno:

Abbiamo preso la decisione di fare qualcosa al riguardo e sembra un problema che potrebbero avere gli altri.

  1. Come si gestisce la migrazione tra un vecchio framework come Betwixt in un nuovo (JAXB, Xstream, qualunque cosa)?

  2. Se dovessimo mantenere il nostro framework: come possiamo gestire la notevole complessità del codice aggiunta dai metodi null e dai falsi setter?

posta Jes 15.05.2014 - 11:41
fonte

1 risposta

2

How does one handle migration between an old framework like Betwixt to a newer (JAXB, Xstream, whatever)?

Crea una nuova implementazione per il tuo livello di accesso ai dati. Se non disponi di un livello di accesso ai dati esplicito, sarebbe un buon momento per presentarne uno! I negozi andranno alla nuova implementazione, i carichi arriveranno dal nuovo, se possibile, o dal vecchio, se necessario.

dataaccess
  +-- betwixt
  +-- jaxb_xstream_whatever

Alcuni potrebbero obiettare che l'intero approccio DAO / DTO è brutto e porta a un aumento di codice e alla duplicazione (mi capita di essere una di quelle persone). Ma spesso ne ho avuto bisogno, e ha salvato progetti grandi e vecchi.

(Disclaimer: non avevo mai sentito parlare di Betwixt prima di oggi, e avevo solo un rapido sguardo alla documentazione.)

If we were to keep our framework: How can we manage the considerable code complexity added by null methods and fake setters?

Idealmente, cambiando i dati in modo che non ne abbiano bisogno. Se ti trovi con un cambio di formato difficile da sposare con un formato precedente, trasferisci tutti i tuoi dati nel nuovo formato. La tua applicazione fa già questo, a tratti, supportando il formato precedente. Stai lavorando con XML, quindi potrebbe essere semplice come alcune trasformazioni XSL.

Se non è possibile migrare i dati in un nuovo formato in massa, è possibile continuare a supportare il formato precedente purché sia possibile rendere getter e setter sensoriali (o almeno deterministici), possibilmente metodi deprecati. O rendili utili, o falli generare eccezioni: se setText non lancia un'eccezione quando lo chiamo, mi aspetto che getText mi restituisca un risultato sensato.

Infine, se il formato è stato modificato a sufficienza da non poter supportare in modo affidabile entrambi i formati in una singola classe, allora stai cercando di inserire nuovi concetti in nomi vecchi, e dovresti davvero creare un tipo di dati diverso, oppure il formato rappresenta una nuova generazione di tipi di dati e dovrebbe sostituire la classe precedente, con il precedente chiaramente contrassegnato come tale ( ThingWithText_v1_8 ).

Da quello che ho raccolto da una rapida occhiata alla documentazione di Betwixt, sono supporta le catene di creazione e più mapping . La mia ipotesi è che potrebbero aiutarti a supportare più formati per tutto il tempo necessario, ma non ho idea di cosa darebbe qualcosa di non troppo fragile.

    
risposta data 18.05.2014 - 18:20
fonte

Leggi altre domande sui tag