Architetture multi-modello multi-DB soluzione ASP.NET MVC

Quando parli con un sistema esterno stai costruendo un'integrazione. Quando ti integri con qualcuno, questo utente non diventa parte del tuo modello di dominio.

Come hai detto, non hai il controllo di quell'altro database. Se un giorno cambiano qualcosa nei loro tavoli, l'intera applicazione diventerà inutilizzabile e ci sarà ben poco da fare se non cambiando la tua applicazione.

Quale integrazione assume normalmente e hai mentorato anche questa è un'API. Se non hai API, ne hai creato uno tuo. Crea un servizio separato che leggerà da quel database e dallo alla tua applicazione principale tramite un'API. Ogni comunicazione che intercorre tra il sistema e un sistema esterno può essere suddivisa in messaggi (uno o due) e richieste di dati su richiesta. Per i messaggi è possibile utilizzare un bus come MassTransit o NServiceBus e creare il proprio modulo, in vaso di NServiceBus, che sarebbe un satellite, per trasferire i messaggi da e verso il database esterno. Se si tratta di richieste di dati su richiesta, è possibile creare il proprio servizio Web che leggerà da quel database esterno e fornirlo al sistema esterno per la lettura tramite chiamate al servizio web.

Il modo in cui lavori con un database esterno all'interno dell'adattatore è di tua scelta. Puoi usare EF se vuoi. Se cambiano il loro tavolo, cambierai semplicemente l'adattatore.

Inoltre, questo approccio dell'adattatore (in realtà questo è un modello di progettazione) che puoi cambiare facilmente quando escono un API appropriato un giorno o possono essere qualsiasi altro metodo come lo scambio di file XML o simili.

E un ultimo commento: il fatto che tu abbia creato un modello in EF designer facendo clic sul pulsante "leggi dal database" o come viene chiamato non significa che tu abbia un modello di dominio. Hai appena ricevuto alcune classi mappate su alcuni tavoli. Alcuni lo chiamano "modello di dominio" ma credetemi, non lo è.

Penso che a un certo punto dovrai scrivere due adattatori. Le interfacce sono un ottimo modo per unire le cose, ma ogni modello deve accedere ai propri dati.

Penso che tu stia seguendo il percorso separando l'accesso ai dati. Se entrambi i modelli interagiscono attraverso un'interfaccia, aggiungere più modelli in futuro sarà più semplice.

Quali oggetti conoscono il contesto delle informazioni che vengono salvate? Riesco a vedere dove potresti avere un paio di oggetti di un tipo di oggetto di istruzione SQL da scrivere nel database. Anche in questo caso, devi ancora tradurre in / dai modelli di dominio.

Buona fortuna.

Facendo un passo indietro rispetto alla tua domanda attuale, potresti trovarti in un mondo intero di dolore se il tappeto viene tirato da sotto di te dall'altro progetto modificandone lo schema.

Riconosci che l'altro sistema non ha un'API da utilizzare. Vorrei spingere affinché questo fosse creato.

L'altro progetto potrebbe non essere in un flusso di lavoro attivo, avere budget ecc., quindi forse il tuo progetto dovrà pagarlo in qualche modo, e forse anche tu dovrai fare il lavoro.