Ho creato un'applicazione con la stessa architettura di dati alle spalle; disponiamo di un database SQL onsite contenente la maggior parte delle informazioni interne e automatiche e di un servizio cloud di terze parti utilizzato per vendite, gestione degli account, personale sul campo, ecc. L'helpdesk ha bisogno di informazioni da entrambe le posizioni fisiche dei clienti e l'attrezzatura, e l'ho ottenuta da due diverse applicazioni fino a quando non sono intervenuta.
Il lungo e breve è che una fonte di dati deve avere un riferimento ai record dell'altro. Nel nostro caso, i dati cloud di terze parti contengono riferimenti ai dati onsite, perché questa è la disposizione su cui abbiamo avuto il controllo maggiore. Ora, con un ID per un record da entrambe le origini dati, possiamo ottenere dati da entrambi; con un ID cloud, estraiamo il record dal cloud, otteniamo l'ID sul posto e recuperiamo i dati onsite. Con un ID in loco, eseguiamo il polling di entrambe le origini dati basate su tale ID.
Nel mio sistema, non ho reso nessun oggetto un figlio dell'altro nel livello del dominio; qualsiasi utilizzo dei dati da entrambi i negozi deve mantenere due istanze di oggetti. Nessuno dei due è garantito per esistere, ed è per questo che l'ho fatto in quel modo; l'app può funzionare solo con dati cloud, o con dati onsite, o entrambi, con più limitazioni e meno dati.
Tuttavia, non è difficile da cambiare, specialmente se sei sicuro che un lato esisterà sempre; semplicemente includere una proprietà nell'oggetto che rappresenta il lato per cui i dati saranno sempre presenti, cioè del tipo di oggetto che rappresenta il record dell'altra archivio dati. È possibile eseguire una "fusione" più avanzata dei due grafici in uno solo.
Questo tipo di accordo deve necessariamente essere accoppiato a un certo livello. È possibile avere un DAL che può interfacciarsi con entrambi gli archivi di dati, oppure è possibile segmentare i DAL, uno per archivio dati e disporre di un livello superiore come un controller per ottenere i dati da ciascuno e collegarli insieme. Ma, a un certo livello, il tuo programma deve avere la capacità di mettere insieme questi due dati di fonti di dati diversi.
È possibile ridurre l'accoppiamento richiesto nella maggior parte dei casi estraendo i dettagli di esattamente da dove provengono i dati. Se ottieni dati da un servizio web, che ti viene dato come istanze di classi generate, inserisci un convertitore per fare una copia profonda della classe di servizio in qualcosa che controlli, che non dovrà cambiare se i dati fonte fa (solo se lo schema lo fa).
Ora, questa può essere un'impresa enorme; il cloud che utilizziamo ha dozzine di classi di dominio, alcune delle quali hanno centinaia di campi di dati, e - ecco il kicker - potresti facilmente apportare grandi cambiamenti al tipo di dati astratti per adattarsi a un passaggio verso un altro cloud o altro fonte di dati. Per quel motivo, non mi preoccupai; Io uso direttamente il dominio del servizio web generato e ora che il passaggio dal cloud a un sito remoto (ma sotto il nostro controllo) è incombente, i dettagli di cui ancora non conosco, sto semplicemente programmando di cambiare i moduli e codebehinds dell'app, che è dove i dati sono "combinati", per riflettere il nuovo schema e / o gli oggetti dati. È un grande lavoro qualunque sia il modo in cui lo dividi.
