Come presentare un modello di dati stabile in un'API pubblica che consente di modificare le strutture di dati interne senza interrompere la visualizzazione pubblica dei dati?

2

Sto sviluppando un'applicazione che consente agli utenti di scrivere script C #. Questi script consentono agli utenti di chiamare metodi selezionati e di accedere e manipolare i dati in un documento. Funziona bene, tuttavia, nella versione di sviluppo, gli script accedono direttamente alle strutture di dati (interne) del documento. Ciò significa che se dovessimo modificare il modello / struttura dei dati interni, ci sono buone probabilità che lo script di qualcuno non venga più compilato. Ovviamente vogliamo evitare che questo cambiamento di rottura accada, ma vogliamo comunque consentire all'utente di scrivere codice C # sensibile (pur non limitando il modo in cui sviluppiamo il nostro modello di dati interno come risultato). Pertanto, abbiamo bisogno di disaccoppiare la nostra API di scripting e le sue strutture di dati dai nostri metodi interni e dalle strutture di dati.

Abbiamo alcune idee su come possiamo consentire all'utente di accedere a quella che è effettivamente una versione pubblica stabile dei dati interni del documento *, ma ho voluto lanciare la domanda là fuori a qualcuno che potrebbe avere qualche reale esperienza di questo problema. NB la struttura dei dati del nostro documento interno è abbastanza complessa e potrebbe essere piuttosto difficile da avvolgere. Sappiamo di voler esporre il meno possibile nella nostra API pubblica, specialmente perché una volta che è là fuori, è fuori là per sempre.

Qualcuno può aiutarti?

  • In che modo i linguaggi / le API di scripting separano le loro API pubbliche e le loro strutture dati dalle loro strutture di dati interne?

  • Non c'è una vera alternativa al dover scrivere un livello di interazione complesso?

    Se abbiamo bisogno di fare questo, qual è un buon approccio o modello per avvolgere strutture di dati complesse che includono oggetti nidificati, comprese le collezioni? Ho esaminato il modello di facciata dell'API, che sembra stia cercando di risolvere questo tipo di problemi, ma ci sono alternative?

* Un'idea è di costruire una facciata di dati che sia mantenuta stabile attraverso le versioni della nostra applicazione. La facciata espone un set di oggetti di dati facciata che vengono utilizzati nel codice dello script. Mantengono la retrocompatibilità e avvolgono l'accesso al modello di dati del nostro documento interno.

    
posta Max Palmer 05.06.2014 - 18:33
fonte

2 risposte

1

La soluzione è pensare seriamente al modello di oggetto presentato e crearne uno che sia adattabile ai cambiamenti futuri (estendibili). L'aggiunta di proprietà non ha intenzione di rompere nulla. Rimuove i tipi di dati, rinominandoli o rimuovendo le proprietà, che interromperà i client esistenti. In questi casi, devi mantenere tutti i membri esistenti per la compatibilità con le versioni precedenti o fornire script di conversione che aggiornano automaticamente gli script dell'utente.

    
risposta data 07.06.2014 - 02:33
fonte
0

Senza conoscere la tua struttura, non sono sicuro che sia esattamente l'idea giusta, ma spiegherò cosa sto pensando e, con un po 'di fortuna, ti porterà all'idea giusta.

Penso che tu voglia una soluzione che sia:

  1. Facile da fare ora
  2. Facile da trasformare se si ripristina la struttura
  3. Un po 'familiare ai tuoi utenti
  4. Ha strumenti disponibili

Quindi stavo pensando a quali strumenti usiamo per interscambiare e trasformare i dati, e quello che mi è venuto in mente era XML.

  1. La maggior parte delle lingue ha una sorta di serializzazione in XML
  2. XML ha strumenti di trasformazione
  3. Ci sono già librerie disponibili per manipolare XML

Quindi il mio piano sarebbe quello di prendere i dati interni e serializzarli in XML. Se lo desideri, puoi usarlo per ora come interfaccia pubblica, oppure puoi trasformarlo in qualcosa di più semplice per renderlo più facile per la successiva iterazione della memoria interna (se riesci a pensare a qualcosa di più semplice). Si lascia iterare l'utente su di esso utilizzando le comuni tecniche XML e, al termine, si può prendere la struttura risultante e trasformarla e de-serializzarla di nuovo nella struttura. Se cambi le strutture, devi solo scrivere una trasformazione diversa.

Naturalmente, non devi usare XML. Ci sono forse altre strutture che potrebbero essere migliori per quello che stai facendo. Con un po 'di fortuna, tuttavia, questo ti farà iniziare sulla strada giusta.

    
risposta data 06.06.2014 - 05:43
fonte

Leggi altre domande sui tag