Ho creato un'app con quasi la stessa architettura di dati dietro di essa; disponiamo di un database SQL in loco contenente la maggior parte dell'automazione e delle informazioni quotidiane interne, quindi un servizio cloud di terze parti utilizzato per vendite, gestione degli account, personale sul campo, ecc. L'helpdesk necessitava di informazioni provenienti da entrambe le posizioni fisiche dei clienti e attrezzature, e l'avevo preso da due diverse applicazioni fino a quando non sono entrato.
Il lungo e breve è che un'origine dati deve avere un riferimento ai record dell'altra. Nel nostro caso, i dati cloud di terze parti contengono riferimenti ai dati onsite perché è la disposizione su cui abbiamo avuto il massimo controllo. 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 in loco e estraiamo i dati in loco. Con un ID in loco, eseguiamo il polling di entrambe le origini dati in base a tale ID.
Nel mio sistema, non ho reso nessuno degli oggetti figlio dell'altro nel livello del dominio; qualsiasi utilizzo dei dati da entrambi i negozi deve conservare due istanze di oggetti. Nessuno dei due è garantito per esistere, motivo per cui l'ho fatto in quel modo; l'app può funzionare solo con dati cloud, o con dati onsite o entrambi, con più limitazioni meno dati ha.
Tuttavia, non è difficile cambiare, soprattutto se si è sicuri che un lato esisterà sempre; includere semplicemente una proprietà nell'oggetto che rappresenta il lato per il quale i dati saranno sempre presenti, ovvero del tipo di oggetto che rappresenta il record dell'altro archivio dati. È possibile una "fusione" più avanzata dei due grafici in uno solo.
Questo tipo di accordo deve necessariamente essere accoppiato ad un certo livello. Puoi avere un DAL in grado di interfacciarsi con entrambi gli archivi di dati, oppure puoi segmentare i DAL, uno per ogni archivio di dati, e avere un livello superiore come un Controller che acquisisca i dati da ciascuno di essi e li agganci insieme. Ma, a un certo livello, il tuo programma deve avere gli strumenti per mettere insieme i dati di queste due diverse fonti di dati.
È possibile ridurre l'accoppiamento richiesto nella maggior parte dei casi estraendo i dettagli esattamente da dove provengono i dati. Se ottieni dati da un servizio web, che ti viene dato come istanze di classi generate, quindi crea un convertitore per creare una copia profonda della classe di servizio in qualcosa che controlli, che non dovrà cambiare se i dati la fonte fa (solo se lo schema 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 dover apportare grandi modifiche al tipo di dati astratto per consentire il passaggio a un altro cloud o altro telecomando fonte di dati. Per questo motivo, non mi sono preoccupato; Uso direttamente il dominio del servizio Web generato e ora che si profila un passaggio dal cloud a un archivio dati fuori sede (ma sotto il nostro controllo), i cui dettagli ancora non lo so, sto semplicemente pianificando di cambiare i moduli e codebehind dell'app, che è dove i dati vengono "combinati", per riflettere il nuovo schema e / o oggetti dati. È un grande lavoro in qualunque modo lo tagli.
