Schema di messaggistica semplice per sostituire il DB condiviso? [chiuso]

3

Ci sono due moduli A e B che utilizzano lo stesso DB. A importa B come JAR. Ho letto che i pattern di messaggistica possono sostituire la soluzione strettamente accoppiata dell'utilizzo di un DB condiviso, ma non sono sicuro di quale schema di messaggi posso usare.

Una soluzione di alto livello che indichi come possiamo smettere di usare il DB condiviso, sarebbe grandiosa.

Aggiunta di ulteriori dettagli come richiesto:

Immagina A come un'enorme app (diciamo Flickr) e B un plug-in per A che periodicamente viene eseguito come un demone e tra le altre cose calcola diversi ranghi dell'utente (ad esempio, l'utente con il maggior numero di commenti, le foto più votate ecc.) . Per fare ciò usa il DB di A e fa la maggior parte dei calcoli usando le stored procedure che vivono ancora nel DB di A.

Il resto del codice è disaccoppiato ma mi chiedevo come perdere la dipendenza dal database, in modo che eventuali modifiche nello schema o implementazione del database non interrompessero B.

    
posta Michael 15.04.2016 - 17:22
fonte

1 risposta

2

Consente di fare un esercizio di creatività

Resto API di A come servizio web : Per alimentare B e unbind B dal modello di dati di A, abbiamo bisogno di un'interfaccia che si comporti come un contratto . Questo contratto sarà il nostro modello di dati del servizio web.

B come app standalone : Consente di avvolgere B in un'app standalone che può essere eseguita ovunque. Il desktop o il web non ha importanza. Diciamo desktop per avviarlo tramite demone O.S.

Ora B è un client di A che richiede le sue informazioni con un modello di dati patto che può essere o non essere come un modello di dati.

Il punto è che il modello di dati del webservice può essere diverso da quello originale.

Inconvenienti :

  • B ha bisogno del proprio modello di dati. Assolutamente
  • Il modello di dati del webservice di A può cambiare nel tempo. Ma abbiamo inventato versioni di restituzione API per questi casi
  • L'accesso al webservice di A dovrebbe essere in qualche modo protetto ( un po 'più di lavoro extra: -) )
  • Se ti aspetti molte richieste da B a A, un sistema di cache sarà necessario ( più lavoro, non mi odi )

Tuttavia, dobbiamo conoscere la configurazione della piattaforma e i suoi limiti. Ma questo sarebbe un possibile approccio.

Spero che ti aiuti.

    
risposta data 15.04.2016 - 19:19
fonte