Dove devo inserire una richiesta API in MVC?

Il modello non è limitato all'interazione con il database, il modello è responsabile per ottenere e manipolare i dati.

Quindi, per la tua vista e il tuo controller, non dovrebbe fare alcuna differenza, se i dati provengono da un database o da un webservice o sono addirittura del tutto casuali, quindi dovresti farlo nel modello.

MVC è un modello di presentazione, che separa solo i diversi livelli di rappresentazione.

Non significa che quel modello deve essere un disordine uniforme di codice spaghetti. Anche il tuo modello può essere stratificato, ma il controllore non dovrebbe sapere da dove provengono i dati.

Un metodo pubblico nel tuo modello può essere strutturato in questo modo (Pseudo-codice), che può essere chiamato dal tuo controller:

public MyDataClass getData(int id) {
    WebServiceData wsData = WebService->getData(id);
    DatabaseData dbData = ORM->getData(id);
    return new MyDataClass(wsData, dbData);
}

WebService e ORM potrebbero dover essere istanze di interfacce che possono essere sostituite da mock tramite dependency injection, ma i controller e le viste non devono essere modificati a scopo di test.

C'è un comune (intenzionale?) equivoco su cosa sono M, V e C. Non riguardo ai ruoli che assumono, ma cosa sono loro.

Nella definizione della GUI desktop originale di MVC, erano moduli . In genere, un'applicazione conteneva alcuni di essi, a volte funzionanti in terzine, a volte con una varietà di visualizzazioni e modelli che alcuni controller potevano combinare.

Nei framework web, OTOH, tendono ad essere visti come layers , dove sono solo uno di ciascuno e si occupa principalmente di coprire alcuni livelli di astrazione sottostanti: "il livello del modello astrae il database", " il livello vista implementa la presentazione "," il livello controller elabora l'input dell'utente ".

Quindi, direi che hai già un modello a , dedicato all'interazione con il database, e ora devi solo creare un altro modello, per gestire il tuo API di origine. Se li rendi il più possibile simili, la maggior parte del controller e del codice di visualizzazione possono funzionare perfettamente con entrambi i modelli.

Parte della difficoltà con qualsiasi discussione su MVC è che diversi gruppi hanno cooptato per significare cose diverse. L'implementazione di MVC utilizzata, ad esempio, in un'app Rails, sarebbe quasi irriconoscibile per chi scrive un'app Swing. Nella misura in cui MVC è ancora una cosa ben definita, è più una serie di principi guida (separare l'applicazione principale dalla sua rappresentazione visiva, fornire meccanismi flessibili per consentire ai due di essere scandagliati insieme), che può essere implementata in vari modi. modi.

In effetti, c'è una tendenza a dare nomi diversi a modelli derivati da MVC diversi (vedi questo articolo di Martin Fowler per alcuni discussione di questo), o anche di rinunciare a una denominazione precisa - ad esempio, AngularJS si descrive come un framework Model-View-Whatever.

Quindi, è difficile rispondere senza sapere quale versione di "MVC" con cui stai lavorando. Tuttavia, una richiesta API di solito fa parte dell'applicazione principale (la parte che non dovrebbe cambiare se si decide di utilizzare una rappresentazione visiva diversa), che in molte implementazioni sarebbe contenuta interamente all'interno del modello.

Il tuo modello non dovrebbe mai contenere alcun codice effettivo, e dovrebbe essere visto come più un messaggio o una struttura utilizzata per gestire il contenuto manipolato dal controller e visualizzato dalla vista.

Il tuo controller dovrebbe essere responsabile di contattare qualsiasi API, database, servizi, ecc ... richiedere una modifica e gestire eventuali aggiornamenti necessari al modello.

L'intera forza del pattern MVC è che disaccoppia la logica (il controller) dalla vista e dallo stato (il modello). In tal modo, ora è garantito che solo il codice nel controller può creare effetti collaterali poiché la visualizzazione e il modello non sono autorizzati a effettuare modifiche.

Consente inoltre un migliore riutilizzo del codice in quanto un modello può essere condiviso tra vari controller e viste.

Qui , il modello è descritto in questo modo:

A model stores data that is retrieved to the controller and displayed in the view. Whenever there is a change to the data it is updated by the controller.

Direi che il controller include la logica di chiamare il servizio o chiama un oggetto Service separato. Se il servizio è separato, puoi più facilmente creare test, ad esempio se non è possibile alcuna connessione a un servizio in rete, alcuni TestService potrebbero fornire risposte dalla Service localmente.

Guarda anche questa risposta che suggerisce che il Controller chiama il servizio.

Potrebbe essere lontano da qui, ma questo è il modo in cui mi sento su WebApps e lavorare con API remote [complesse] in molti casi:

Lo farei una classe (cioè una libreria di metodi di mitigazione dei dati) anziché un modello (cioè una pila di funzioni di mitigazione dei dati). Sembra che agisca in modo più trasparente, più logico e indipendente dallo schema, e potresti usarlo ovunque senza caricare - > chiamare un modello / controller stesso ogni volta che vuoi usarlo. La logica è ancora separata, il datapoint è ancora flessibile e sembra più aperto all'interoperabilità in casi strani come lo stacking clientAJAX- > appJSON- > appLIB- > remoteAPI- > remoteJSON etc per eseguire il polling indiretto dell'endpoint.