Trasferimento dati tra il sito "principale" e il sito virtuale protetto

Suggerirei Opzione n. 4: creare una libreria di classi che racchiuda questa funzionalità condivisa che entrambi i siti potrebbero aggiungere come riferimento in Visual Studio.

Questo nuovo progetto sarebbe una libreria di classi in Visual Studio. Avrebbe modelli di dominio che impongono la logica aziendale della creazione di un nuovo lead e che avrebbe le classi repository che eseguono gli INSERT, gli UPDATE e il DELETE effettivi dal database, nonché il recupero dei dati.

Mentre le persone tendono a gravitare immediatamente verso i servizi REST, poiché entrambi i siti utilizzano entrambi il framework .NET, una libreria di classi condivisa sarà più facile da costruire, distribuire e mantenere a lungo termine. Inoltre, non dovrai sostenere l'overhead aggiuntivo di fare richieste HTTP e gestire le risposte, il che renderà entrambe le applicazioni più veloci per queste operazioni.

Mi piace tenere a mente il consiglio di Martin Fowler per quanto riguarda Microservices (che si applica all'architettura orientata ai servizi in general):

First Law of Distributed Object Design: "don't distribute your objects"

Creare un servizio REST è solo un altro modo di "distribuire i tuoi oggetti" poiché questi oggetti devono esistere in entrambe le applicazioni e devono anche essere serializzati e deserializzati per il transito su una rete.

Continua a giustificare questa "legge":

My objection to the notion of distributed objects was although you can encapsulate many things behind object boundaries, you can't encapsulate the remote/in-process distinction. An in-process function call is fast and always succeeds (in that any exceptions are due to the application, not due to the mere fact of making the call). Remote calls, however, are orders of magnitude slower, and there's always a chance that the call will fail due to a failure in the remote process or the connection.

(Enfasi, mia)

Perché gestire una connessione di rete volubile e uno stack di applicazioni Web quando è possibile effettuare chiamate in-process allo stesso database? Quello che stai davvero cercando di evitare è il codice duplicato. Questo permette di creare una libreria di classi condivisa per i tuoi due progetti .NET.

Applicazioni multiple, stack tecnologici diversi

Se avessi una applicazione pubblica scritta in Java e la tua applicazione di back-office scritta in C # avresti un buon caso per una delle due soluzioni:

1. Crea stored procedure nello stesso database che vengono chiamate da entrambe le applicazioni

2. Crea un servizio REST chiamato da entrambe le applicazioni

Anche in questo caso, vorrei andare con le stored procedure prima di creare un servizio web. Se le tue applicazioni pubbliche e di back-office devono gestire "lead" e hai un'app Android e iOS che fa la stessa cosa, creerei un REST o un servizio web. I servizi Web iniziano a brillare in ambienti multipiattaforma in cui una o più piattaforme sono "lato client" (vale a dire in un browser, un'app mobile o un'azienda di terze parti deve utilizzare questa funzionalità).

Se sono solo i siti Web di te e della tua azienda, vai prima con una libreria di classi, poi con le stored procedure e come ultima risorsa per creare un servizio web.

Penserei che l'opzione 3 sarebbe l'opzione migliore. Passerai i dati tramite un servizio per inserire i dati nel tuo database. Ovviamente dovresti controllare che cosa sta chiamando il tuo servizio, magari un cert sul lato client, un controllo dell'intervallo di indirizzi IP, controllare i dati.