Dovremmo chiamare l'API Web dall'applicazione MVC nella stessa soluzione?

Sto lavorando a un progetto in MVC che ha un'applicazione mobile, quindi una cosa è chiara che dobbiamo usare l'API Web in modo che possa essere utilizzata nell'applicazione mobile.

Dopo aver creato l'API quando abbiamo iniziato a sviluppare un sito Web, siamo confusi e abbiamo discusso sull'uso dell'API o sull'accesso diretto all'oggetto Business. E siamo finiti dopo aver avuto lo sviluppatore più esperto di un'opinione per consumare API Web invece di utilizzare direttamente l'oggetto Business.

Sto avendo confusione riguardo a questa struttura di soluzione.

1) Perché dovremmo usare l'API Web e fare una richiesta HTTP (che richiede tempo) per ottenere o inserire dati anziché oggetti business direttamente nella stessa soluzione.

2) Dopo aver litigato, hanno detto che cosa succede se il client vuole ospitare API e web su diversi server cloud e applicare il ridimensionamento solo su API o potrebbe voler avere un URL diverso per accedere all'API e al Web (che è logico). Quindi in quel caso dovremmo chiamare l'API Web dall'applicazione MVC nella stessa soluzione?

3) Se stiamo ospitando API e Web su hosting diverso, ciò significa che il nostro Web utilizzerà WebClient e avrà chiamate HTTP su ogni navigazione. È giusto?

4) Se avremo un oggetto business sia dall'API che dall'hosting Web su server diversi, allora se qualcosa di diverso in BL dovrà essere aggiornato su entrambi i server.

5) Oppure dovremmo creare un solo progetto per API e aggiungere viste o pagine html per sviluppare l'interfaccia Web in modo da poter chiamare direttamente API da ajax.

Secondo la mia conoscenza # 5 è la migliore soluzione o API è solo per l'accesso di terze parti. Se abbiamo DB, EF, livello dati e livello aziendale nella stessa soluzione, non dovremmo usare l'API per effettuare chiamate HTTP e accedere direttamente all'oggetto business. (correggimi se sbaglio) L'API è necessaria quando l'applicazione mobile o il desktop o qualcuno vuole accedere all'applicazione in modo da poter avere lo stesso repository e lo stesso livello di dati.

Nel mio scenario devo creare API poiché abbiamo anche un'applicazione mobile e nel lato API del progetto abbiamo chiamato il livello aziendale (progetto separato) e il livello aziendale comunicano con il livello di accesso ai dati (progetto separato). Quindi la mia domanda è se ospitiamo la nostra API e il nostro web su server diversi, quindi chiamare l'API che è una richiesta HTTP potrebbe richiedere più tempo invece di usare il metodo dal livello aziendale mentre creiamo il progetto e abbiamo .dll del livello aziendale. Nel controller API convertiamo semplicemente la nostra attività in formato json.

Ho cercato su internet ma non ho avuto una risposta convincente. Ho trovato un blog http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx discutendo ancora dello stesso punto in quel blog la mia domanda è: perché dobbiamo considerare lo scenario n. 3?

Aggiornamento: possiamo avere diversi progetti API e progetti MVC e possiamo chiamare API dal web usando jvascript o usare il modello MVVM.

Ottima domanda! Cerco sempre un modo migliore per strutturare i miei progetti. Ogni punto che sollevi ha valore e dopo aver esplorato una varietà di strutture di soluzioni, devo dire che sono d'accordo con la maggior parte dei commenti qui: non esiste una soluzione perfetta. Alcune cose da porsi di fronte a questo tipo di problema: quanto è complessa questa applicazione? Con quanti sistemi avrò bisogno di integrare - o quanti sistemi dovranno integrarsi con questo sistema? Quanti test ho intenzione di fare? Esiste un team di progettazione / interfaccia utente separato? Dovremo ridimensionare? Cosa costituisce una sessione?

Diamo un'occhiata a un paio di scenari e modi per usare un po 'di ingegneria intelligente per far esplodere le cose (e alcuni trucchi per rendere le cose un po' più facili) ..

Ospitare API e sito Web nello stesso progetto
In questo caso, potresti avere un'unica soluzione con zero o più progetti di livello aziendale e un singolo progetto ibrido MVC / WebAPI (così come altri progetti - utilità, ecc.).

Pro's
Tutto è in un unico posto .. Non c'è bisogno di usare le scarpe in messaggistica complicata (chiamate HttpClient), puoi avere uno stato di sessione condiviso (client e server tramite cookie, sessione InProc / OutOfProc, ecc.), Pool di connessioni, logica condivisa, ecc. La distribuzione non potrebbe essere più semplice.

Con's
Tutto è in un unico posto .. Questa è probabilmente la struttura più monolitica possibile. Non ci sono interfacce chiaramente definite tra i tuoi livelli. Finisci per avere una coesione elevata . Gli sviluppatori pigri eviteranno le interfacce quando si occupano di questo tipo di architettura, il che rende i test un problema enorme. Il ridimensionamento / la localizzazione dell'applicazione sarà difficile.

Usi Userei
questa struttura di progetto per un'applicazione una tantum, interna o semplice. Costruire un sistema rapido per tracciare l'iscrizione al campo da basket presso la Y locale? Questa è la tua architettura!

WebAPI e sito Web in diversi progetti
Tendo a preferire questo caso. Hai un'unica soluzione con uno (o più) progetti MVC e un progetto WebAPI.

Modularizzazione di Pro ! Accoppiamento lasco! Ogni progetto può essere autonomo, testato separatamente e può essere gestito in modo diverso. Ciò consente di implementare più facilmente diverse strategie di memorizzazione nella cache in base alle proprie esigenze. Mantenendo solidi confini tra i diversi sistemi, è possibile stabilire più facilmente contratti che consentono di applicare schemi di utilizzo specifici e ridurre i possibili attriti (leggi: meno bug con meno opportunità di abusare dell'API). Il ridimensionamento è un po 'più semplice in quanto è necessario solo ridimensionare i bit che vedono un carico elevato. Anche l'integrazione diventa un po 'più facile da gestire perché dovrai avere un'idea di come sarà la tua API fin dall'inizio.

La
manutenzione di Con è un po 'più difficile. Più progetti significa che avrai bisogno dei proprietari di progetti / funzionalità per tenere traccia di fusioni, contratti (interfacce), distribuzioni, ecc. Manutenzione del codice, debito tecnico , tracciamento degli errori, gestione dello stato - tutti diventano problemi in quanto potrebbero dover essere implementati in modo diverso sulle tue esigenze. Questi tipi di applicazioni richiedono anche la massima pianificazione e cura man mano che crescono.

Utilizzi
Creazione di un'applicazione che potrebbe avere 100 utenti oggi e 100.000 la prossima settimana / mese? L'applicazione deve inviare notifiche, gestire flussi di lavoro complessi e avere più interfacce (web + app mobile + SharePoint)? Hai un sacco di tempo a disposizione e ami risolvere i puzzle di oltre 5000 pezzi nel weekend? Questa è l'architettura per te!

Suggerimenti
Dopo aver delineato quanto sopra, posso capire come il tuo prossimo progetto potrebbe sembrare un po 'scoraggiante. Nessun problema, ecco alcuni trucchi che ho imparato negli anni ..

1. Prova a usare sessioni senza stato. Su sistemi più piccoli, ciò potrebbe significare la memorizzazione di un cookie crittografato contenente almeno l'ID interno dell'utente corrente e un timeout. Sistemi più grandi potrebbero significare la memorizzazione di un cookie crittografato con un semplice ID di sessione che potrebbe essere recuperato da un archivio dati (redis, archiviazione tabelle, DHT , ecc.) Se riesci a memorizzare abbastanza informazioni in modo da non dover colpire il database principale su ogni richiesta ti troverai in un buon posto, ma cerca di mantenere i cookie sotto 1k.
2. Tieni presente che probabilmente ci sarà più di un modello. Prova a pensare in termini di modelli e proiezioni (i collegamenti che ho trovato qui erano .. non va bene .. pensa: l'articolo di inventario di un uomo è un elemento pubblicitario di un altro uomo - stessa struttura di base di base, ma viste diverse). Alcuni progetti hanno un modello diverso per ciascun confine logico / concettuale (ovvero utilizzando un modello specifico per la comunicazione con un'API specifica.
3. L'API è ovunque! Ogni volta che un oggetto / classe / struttura espone dati o comportamenti, si sta stabilendo un'API. Prestare attenzione a come altre entità o dipendenze utilizzeranno questa API. Pensa a come potresti testare questa API. Considera cosa potrebbe parlare a questa API (altri oggetti tramite codice? Altri sistemi tramite un protocollo?) E come vengono esposti i dati (fortemente tipizzati? JSON? * Tosse * XML?).
4. Costruisci per quello che hai, non per quello che immagini che avrai tra due anni. Un'altra risposta fa riferimento a YAGNI : sono assolutamente corretti! Risolvere problemi immaginari rende immaginaria la tua scadenza. Stabilisci obiettivi concreti per le tue iterazioni e raggiungili. Deploy! Un progetto in sviluppo è un progetto con un solo utente - tu!
5. YMMV (il tuo chilometraggio può variare). C'è solo un assoluto qui: c'è un problema, stai costruendo una soluzione. Tutto il resto è completamente in aria. Entrambe le soluzioni di cui sopra possono essere un successo sfrenato e un fallimento di succhiare. Dipende tutto da te, dai tuoi strumenti e da come li usi. Percorri leggermente, collega sviluppatore!

L'accesso diretto ai tuoi oggetti business direttamente (presumo tu intenda nel tuo controller) sarà più veloce e più facile.

cosa succede se il cliente vuole ospitare API e web su diversi server cloud e applicare il ridimensionamento solo su API o potrebbe voler avere un URL diverso per accedere a API e Web (che è in qualche modo logico)

Quindi dovrai ospitarli separatamente ... ma non mi sembra molto logico, sicuramente vorrai ridimensionarli entrambi. Sei sicuro di dover soddisfare questo requisito? Sembra eccessivo. Ricorda YAGNI: se non ti serve, non costruirlo. Quando ne hai bisogno, costruiscilo.

Se fossi in me costruirei il sito usando la tecnologia che si adatta meglio al sito, quindi quando (se) hai bisogno di un servizio che altre persone possono chiamare costruirlo separatamente.

Direi; preferisce MVC chiamando WebAPI tramite HTTPClient. È travolgente andare attorno alla logica "core dll", ma il vantaggio principale è che il tuo sistema generale avrà un unico punto di accesso agli oggetti di dominio su HTTP ... Comunque in fondo ... con la raccolta di Micro Service Architecture e le app che stanno già passando a Client Side Frameworks (AngularJS ecc.) .... meglio trattare MVC come un altro client ... e insegnare al team a gestire bene le API ...

TIENI SEMPLICE. Spero che questo aiuto. Grazie..