Dove devo inserire una richiesta API in MVC?

25

Sto creando un'applicazione Web usando un modello MVC. Seguendo questo tipo di architettura possiamo vedere che tutti i metodi usati per interagire con il database sono implementati nel modello .

Ma cosa succede se devo chiamare un servizio esposto da altri sul web? Ad esempio, vorrei accedere all'API di Facebook per ottenere tutti i follower della mia pagina, quindi, dove ho inserito questi metodi?

Ovviamente la vista non è una buona idea perché questo modulo è dedicato alla presentazione, il controller non dovrebbe essere usato per recuperare i dati ma il modello è di solito dedicato solo all'interazione con il database.

Quindi, puoi darmi qualche suggerimento al riguardo? E per favore, puoi dirmi se sto facendo degli errori sull'architettura MVC?

mvc api

— Ema.jar
fonte

2

Penso che le persone sarebbero in grado di fornire risposte migliori se elencassi alcune delle librerie e dei framework che stai utilizzando per supportare la tua applicazione MVC. Mentre il modello MVC è indipendente dalla tecnologia, non tutti i framework lo seguono esplicitamente. Inoltre, la maggior parte dei framework maturi ha già una documentazione eccezionale e sapere quale si sta usando renderebbe più semplice indirizzarti a una spiegazione preesistente che segue la tua linea di pensiero.

— CLW

2

Banca dati? Fonte di dati? Sono solo dati.

2

Ci sono così tante opinioni su ciò che dovrebbe essere "MVC", che questa domanda è troppo astratta per rispondere.

— Remco Gerlich,

2

Inoltre, considera la possibilità di chiamare l'API dal tuo codice Javascript front-end e di non toccare affatto le tue cose "MVC" del back-end.

— Remco Gerlich l'

@Remcogerlich è per questo che ho proposto un'aggiunta dell'attuale implementazione che sta guardando. Potrebbe avere a che fare con un backend e un'implementazione di frontend di mvc. Potremmo anche disporre di un altro modello che spieghi meglio queste differenze.

— CLW,

37

Il modello non si limita all'interazione con il database, il modello è responsabile della raccolta e della manipolazione dei dati.

Quindi, a tuo avviso e controller, non dovrebbe fare alcuna differenza, se i dati provengono da un database o da un servizio web o sono addirittura totalmente casuali, quindi dovresti farlo nel modello.

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

Ciò non significa che quel modello debba essere un pasticcio uniforme di codice spaghetti. Anche il tuo modello può essere stratificato, ma il controller 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);
}

WebServicee ORMpotrebbe essere necessario che siano istanze di interfacce che possono essere sostituite da simulazioni tramite iniezione di dipendenza, ma i controller e le visualizzazioni non devono cambiare a scopo di test.

— residuum
fonte

8

Il modello non dovrebbe avere alcuna logica e quindi non interagire direttamente con nulla. Il modello MVC richiede chiaramente che tutta la logica venga inserita nei controller. Questi controller dovrebbero contattare il DB, l'API, ecc ... e aggiornare il modello, se necessario. Ciò mantiene agnostica la tecnologia del modello e garantisce che non serva altro che un meccanismo di archiviazione che può essere passato a varie visualizzazioni per presentazioni e controller per ulteriori manipolazioni.

— CLW

3

@CLW: Modello! = Modello dati. Maggiori dettagli possono essere trovati da qualche altra parte, ad esempio stackoverflow.com/a/14045514/124983

— Residuum

2

@CLW: la logica aziendale non dovrebbe essere in M, V o C. I modelli sono un'astrazione di un archivio dati, viste e controller sono la tua interfaccia utente. Sono la periferia dell'applicazione reale che stai creando, che dovrebbe essere "solo codice", che non deve conoscere cose come i database e il web.

— Remco Gerlich l'

2

La parte "modello" viene interpretata in centinaia di modi diversi. Mi è sempre stato insegnato che un modello è una rappresentazione. Un treno modello è la rappresentazione di un treno reale, con piccole parti mobili che si muovono proprio come quello reale. Allo stesso modo, il modello nella tua app è una rappresentazione dei sistemi e dei processi che stai costruendo per sostituire il tuo software. Pertanto, i modelli hanno un comportamento . Tale comportamento incorpora la tua "logica aziendale". Pertanto, quando si ignora l'accesso ai dati CRUD, l'interfaccia utente e l'interoper, ciò che rimane è probabilmente il tuo "modello" - classi di dominio, regole aziendali, ecc.

— anaximander,

1

@RemcoGerlich Non ho detto nulla sulla logica aziendale. Ho semplicemente affermato che, poiché la maggior parte delle interpretazioni di MVC richiedono che il modello non sia altro che una semplice struttura che rappresenta lo stato dell'applicazione, che la responsabilità di contattare il DB, l'API, ecc ... non dovrebbe essere inserita nel modello perché dovrebbe essere senza logica. L'obbligo di comunicare con il database dovrebbe ricadere sul controller o su un altro oggetto gestito dal controller.

— CLW,

12

C'è un malinteso comune (intenzionale?) Su cosa siano M, V e C. Non sui ruoli che assumono, ma quali sono .

Nella definizione GUI desktop originale di MVC, erano moduli . In genere un'applicazione ne aveva diverse, a volte funzionanti in terzine, a volte con una varietà di viste e modelli che alcuni controller potevano combinare e abbinare.

Nei framework web, OTOH, tendono ad essere visti come livelli , in cui sono solo uno di ciascuno e si occupano principalmente della copertura di un livello di astrazione subcentrico: "il livello del modello estrae il database", "il livello della vista implementa la presentazione", "il controller il livello elabora l'input dell'utente ".

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

— Javier
fonte

1

Concordato: i modelli dovevano sempre essere l'intero dominio del problema. Nelle app complicate doveva sempre essere la maggior parte del codice. Consistevano in tutto il codice che non cambierebbe se cambiassi l'interfaccia utente (diciamo, dal sito Web alla GUI o persino all'applicazione della riga di comando). Pensa a un compilatore. Solo una porzione molto piccola del codice cambierebbe se si passasse da un'interfaccia utente della riga di comando a una GUI o persino all'interfaccia utente Web. Tutte le viscere di tale applicazione sono i modelli.

— Kevin Cathcart,

1

Nell'uso originale di Smalltalk del termine, ogni controllo dell'interfaccia utente nell'interfaccia aveva il proprio modello, vista e controller.

— Remco Gerlich l'

5

Parte della difficoltà con qualsiasi discussione su MVC è che diversi gruppi lo hanno cooptato per significare cose diverse. L'implementazione di MVC utilizzata, ad esempio, in un'app Rails, sarebbe quasi irriconoscibile per qualcuno che 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 collegati insieme), che possono essere implementati in vari modi.

In effetti, c'è la tendenza a dare nomi diversi a diversi modelli derivati da MVC (vedi questo articolo di Martin Fowler per una discussione di questo), o addirittura a rinunciare a una denominazione precisa - ad esempio, AngularJS si descrive come un modello-vista-qualunque cosa struttura.

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

— James_pic
fonte

2

Qui , il modello è descritto in questo modo:

Un modello memorizza i dati recuperati nel controller e visualizzati nella vista. Ogni volta che viene apportata una modifica ai dati, questi viene aggiornato dal controller.

Direi che il controller include la logica di chiamare il servizio o chiama un Serviceoggetto separato . Se il servizio è separato, è possibile creare più facilmente test, ad esempio, se non è possibile alcuna connessione a un servizio su una rete, alcuni TestServicepotrebbero fornire risposte a Servicelivello locale.

Controlla anche questa risposta che suggerisce che il controller chiama il servizio.

— nullo
fonte

2

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

Il responsabile del trattamento dovrebbe essere responsabile del contatto con qualsiasi API, database, servizi, ecc ... per richiedere una modifica e gestire gli eventuali aggiornamenti necessari al modello.

L'intero punto di forza del modello MVC è che disaccoppia la logica (il controller) dalla vista e dallo stato (il modello). In tal modo, ora sei garantito che solo il codice nel controller può creare effetti collaterali poiché la vista e il modello semplicemente non sono autorizzati ad apportare modifiche.

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

— CLW
fonte

4

Penso che quando dici "modello" qui, ti riferisci a "modello", che l'IMO è una cosa separata. Un viewmodel ottiene i dati dal controller alla vista, e come tale è un dettaglio di implementazione della Vista o un aspetto delle comunicazioni tra Vista e Controller che non si adatta a nessuno dei due (dipende da come lo vedi). Il "Modello" in MVC si riferisce a un modello di sistema - una rappresentazione del sistema che incorpora i suoi dati, struttura e comportamento. Il modello è stato e logica; il controller è ciò che causa l'esecuzione della logica e lo stato che cambia quando viene manipolata la vista.

— anaximander,

@anaximander No Mi riferisco al Modello in un'interpretazione abbastanza rigorosa di MVC (vedi Wikipedia, Microsoft MVC, Head First Design pattern, ecc ...) In quei casi il Modello non è altro che una semplice struttura per il passaggio di dati intorno e non esiste un modello di visualizzazione. Mentre l'implementazione di Microsoft MVC aggiunge vari attributi al modello, questo è più comodo che altro. Alla fine lo scopo del modello MVC era di facilitare le buone pratiche di separazione del codice e limitare gli effetti collaterali.

— CLW,

1

Potrebbe essere molto diverso qui, ma è così che mi sento su WebApps e lavorare con API remote [complesse] in molti casi:

Vorrei renderlo 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 agirebbe più trasparente, più logico / agnostico dello schema e potresti usarlo ovunque senza caricare-> chiamare un modello / controller stesso ogni volta che vuoi usarlo. La logica è ancora separata, il punto dati è ancora flessibile e sembra più aperto all'interoperabilità in strani casi come impilare clientAJAX-> appJSON-> appLIB-> remoteAPI-> remoteJSON ecc per eseguire il polling dell'endpoint indirettamente.

— dhaupin
fonte