MVCS - Model View Controller Store

Di recente ho deciso di iniziare a studiare lo sviluppo di iOS e, a tal fine, ho letto la programmazione per iOS: The Big Nerd Ranch Guide . Nel libro gli autori descrivono un modello di progettazione MVCS - Model-View-Controller-Store , l'idea di base è che poiché molte applicazioni fanno uso di più fonti esterne di dati mantenendo la logica di richiesta nel controller può diventare molto confusa, invece gli autori propone di spostare tutta la logica di richiesta fuori dal controller e in un oggetto separato.

In breve, per citare il libro

Model-View-Controller-Store inserisce la logica di richiesta in un oggetto separato e chiamiamo questo oggetto un archivio (Figura 28.4). L'uso di un oggetto store minimizza il codice ridondante e semplifica il codice che recupera e salva i dati. Ancora più importante, sposta la logica per trattare con una fonte esterna in una classe ordinata con un obiettivo chiaro e mirato. Ciò semplifica la comprensione del codice, facilita la gestione e il debug, nonché la condivisione con altri programmatori del tuo team.

E

La cosa interessante degli archivi asincroni è che anche se molti oggetti stanno facendo molto lavoro per elaborare una richiesta, il flusso della richiesta e la sua risposta sono in un posto nel controller. Questo ci dà il vantaggio di un codice facile da leggere e anche facile da modificare.

Volevo saperne di più su questo schema e vedere cosa avrebbero potuto dire gli altri al riguardo, ma durante la ricerca online gli unici riferimenti che ho potuto trovare erano sullo stesso libro (lo schema è forse conosciuto con qualche altro nome?).

Per me la logica dell'autore sembra avere senso e sembra un'estensione logica del modello MVC normale, ma forse è perché non ho molta esperienza con il modello MVC in pratica (a parte l'incursione nello sviluppo di iOS che ho sorta di MVV usato con backbone.js (cioè se lo consideri MVC )).

Speravo che forse qualcuno con più esperienza potesse far luce sul fatto che ci siano evidenti difetti / problemi con il modello MVCS che mi manca.

"Store", nel caso dei modelli di progettazione MVCS, tende ad inclinarsi verso la logica di archiviazione. Nel caso di iOS, di solito si tratta di un'implementazione di Core Data. Se crei un modello supportato da Core Data in Xcode, vedrai l'aspetto "Store" di questo modello di design nascosto nella classe AppDelegate.

Per portare questo al livello successivo, creerò spesso una classe gestore singleton che gestisce l'impostazione dello stack di dati principali e si occupa di tutto il recupero / salvataggio che è coinvolto nello stack. Come dice la citazione che hai citato, questo rende molto semplice non solo chiamare quei metodi, ma anche regolarli se necessario, invece di avere il salvataggio / recupero delle chiamate in tutto il luogo in diversi controller di visualizzazione.

Il paradigma "Store" non è limitato ai Core Data, però. Il tuo negozio potrebbe essere solo un servizio web. Forse hai una lezione che interagisce con Facebook, Twitter, Yelp o altre API basate su REST. Ho scoperto (e allo stesso modo seguo la tendenza) che anche questi tipi di classi si chiamano Manager. Stanno gestendo letteralmente tutti i dettagli interni in modo che le altre tue classi possano semplicemente inserire o ottenere esattamente ciò di cui hanno bisogno.

Per quanto riguarda evidenti difetti o problemi con questo modello di progettazione ... Come con qualsiasi modello di progettazione, il problema più evidente è garantire che il progetto sia stato impostato in modo tale da favorire il paradigma. Soprattutto con un modello di design che è nuovo per te, questa a volte può essere la parte più difficile. Il vantaggio di suddividere la logica del "Negozio" nella propria classe è il fatto stesso che rende molto più semplice la manutenibilità del codice.

"Conservare" in questo contesto sembra molto simile a un repository o un servizio . In tal caso, questo è un modello estremamente comune. I difetti / problemi varieranno con l'implementazione e il dominio del problema.

A livello generale, sembra che il libro stia usando "Store" per rappresentare un livello di logica aziendale + un livello di logica di recupero dei dati che gestisce un insieme di dati che possono o meno far parte dell'applicazione.

Ad esempio, avvolgere l'api di twitter in un 'Store' è un bel modo di compartimentare quella logica.

Dopo ulteriori riflessioni
Usando questa definizione di MVC (che ritengo sia abbastanza precisa), lo "Store" è davvero un sottoinsieme del modello. La delimitazione tra se si tratta di un'estensione di MVC o se si tratta di un modello di recupero dei dati non è estremamente utile. Finiscono per sembrare lo stesso codice.

In conclusione, penso che starai bene seguendo i consigli che suggeriscono (nel complesso sembrano buoni).