Organizzazione dell'app MVC con modello virtuale utilizzando l'API esterna

Il mio istinto mi dice che hai ragione a voler inserire del codice nel Modello. Il fatto è che mentre quelli sono i requisiti funzionali / non funzionali della tua applicazione oggi, ciò potrebbe cambiare. Potrebbe essere richiesto di implementare un database alla successiva iterazione di questo progetto, o ancora peggio l'intero modo in cui stai memorizzando i dati potrebbe essere revisionato.

Il fatto è che cambiano le cose. Migliore è la modularizzazione e l'astrazione del codice, più velocemente sarai in grado di adattarti a cambiare strada. Potrai anche impostare te stesso per semplificare i test di unità e integrazione. Questo è un fattore importante, perché rilevare i problemi prima che diventino problemi consente di risparmiare tempo e reputazione.

Non ho familiarità con Rails, ma teoricamente, per mantenerlo strettamente MVC, dovresti incapsulare la gemma nel tuo modello (il tuo secondo metodo).

Se la tua gemma definisce già tutte le strutture di dati necessarie, potresti decidere di chiamare la gemma il tuo 'modello' anche se potrebbe risiedere in una posizione non convenzionale (di nuovo, non ho familiarità con Rails quindi forse puoi mettere un gemma dove vuoi?). Avrai sicuramente bisogno di passare i dati ai metodi della gemma e recuperare i dati, il che rende implicitamente quei parametri e restituisce il valore del tuo modello.

Non c'è niente di sbagliato nell'avere un modello statico. In realtà gli appassionati di funzionalità lo adorerebbero in questo modo.

Se non disponi di troppi modelli e assicurati che ciò avvenga, crea un modello virtuale o, se è diverso, e se l'API supporta JSON, utilizza la libreria JSON. Non lo fa senso di trasformare i dati se non stiamo andando a fare qualsiasi post-elaborazione su oggetto.