Sono necessarie due applicazioni web .net?

Solo due? In questi giorni i microservizi sono "in" e non è raro che una soluzione sia composta da 2 o 3 ma a volte decine di servizi separati. Sto lavorando a una soluzione che ha circa 45 al momento.

Separare i servizi in questo modo consente diversi vantaggi: ad esempio, è possibile eseguire la versione e distribuirli singolarmente, in modo che il ciclo di test e release per una piccola modifica possa essere molto più breve e le implementazioni siano molto meno rischiose.

Hai anche opzioni di ridimensionamento più flessibili; ad esempio, se un particolare servizio riceve molto traffico, puoi attivare quel servizio specifico su più nodi (aggiungendo macchine alla tua web farm con carico bilanciato o eseguendo una configurazione cloud con capacità più elevata).

Se fossi in me, non avrei alcun problema a separare i servizi web dal sito web, come nella tua domanda. In questo modo, ad esempio, la modifica del formato di una pagina non richiede di eseguire il test di regressione anche sui servizi, poiché sono basi di codice indipendenti e processi indipendenti.

Non ci sono molti motivi per tenerli insieme. Ce ne sono alcuni per renderli separati, e tutti lo stanno facendo in questi giorni.

Ci possono essere molte ragioni per separare o combinare progetti. Spesso ho questa testa in testa che strada da percorrere, ma ho riassunto le decisioni in basso:

1. È l'applicazione principale: MVC (Controller); e i servizi Web: RESTful (ApiController). Si tratta di sistemi di instradamento separati ed è più semplice da gestire se si tratta di progetti separati.

2. Isolamento da errore di distribuzione. Se si desidera solo modificare uno stile CSS nell'applicazione principale, perché la distribuzione dovrebbe interessare anche molte altre parti del sistema? Questa è una buona ragione per cui le risorse HTML statiche sono separate dalla generazione di pagine dinamiche e dalle apis web.

3. Vuoi evitare la configurazione di CORS? Forse non ti piace usare le cartelle virtuali, nel qual caso sarebbero necessari domini o sottodomini separati per ogni progetto separato. Non penso che questa sia una singola ragione per combinare progetti, ma certamente, un fattore da considerare.

4. C # e EF impiegano un po 'di tempo per "riscaldarsi". Se non trascorri del tempo su ngen, caching di query EF e codice per "testare" gli endpoint e manualmente "scaldare" gli endpoint del codice, troverai un progetto monolitico molto grande per avere un ritardo più lungo sulla prima richiesta web.

5. Principi modulari / IoC / solidi. Il web è già modulare, in cui un URL può portare l'utente a un server completamente diverso. (Ciò potrebbe significare l'interoperabilità tra molte piattaforme e lingue diverse come un'unica "soluzione"). Avendo progetti separati, uno limita l'accoppiamento (o almeno lo rende molto visibile), e in tal modo rende più semplice e modulare la manutenzione, l'estensione e la ricostruzione in futuro. Se il progetto A e B funzionano e vuoi costruire C, a chi importa quale stack o lingua A e B sono. È importante però se si tratta di un singolo progetto monolitico.

Ovviamente, tutti i punti sopra dipendono dalla scala della base di utenti e dalla dimensione del progetto. Se si tratta di "Hello world" per una persona, sarebbe eccessivamente ingegneristico avere IoC, Progetti separati, JWT, ecc ...