Tratta i servizi Web come qualsiasi altro accesso ai dati:
Per avvicinarci all'architettura MVC lato client, senza framework, abbiamo trattato i servizi Web nello stesso modo in cui abbiamo eseguito localStorage e il database IndexedDB locale. Tutto il codice che coinvolge richieste a server remoti o che eseguono query su un database o che legge / scrive su localStorage si verifica nel livello del modello come oggetti DAO.
Questi sono stati scritti usando il modello del prototipo, il modello del modulo, o in alcuni casi una combinazione dei due, usando un modello di fabbrica modificato per trattare gli oggetti come singleton in produzione ma permettendoci di "resettarli" quando testare l'unità in modo teniamo i test auto-contenuti.
Sono generalizzati in modo che in questo livello non esista alcuna logica applicativa e la maggior parte del codice a questo livello può essere essenzialmente riutilizzato in future applicazioni.
Il livello di servizi incapsula il livello DAO, mantenendo la tecnologia di archiviazione specifica separata dalla logica del controller. Pertanto, la spinta dei dati su un server remoto è vista come l'inserimento di dati in IndexedDB.
Usato XMLHttpRequest non elaborato per interfacciarsi con i servizi Web:
Abbiamo scelto di non utilizzare jQuery AJAX. Invece, abbiamo scritto un wrapper su XMLHttpRequest. Non c'è una risposta giusta o sbagliata qui, ma scegliere di non usare jQuery qui ci permette di rimanere concentrati sulla regola di non avere manipolazioni DOM in questo livello. Con il wrapping della logica AJAX all'interno di una classe prototipo, impostiamo alcune intestazioni predefinite, poiché la maggior parte di ciò che i servizi Web trattano nel nostro caso sono dati di applicazione / json.
Tuttavia, abbiamo fatto un'eccezione per jQuery Deferred. Non sembrava avere senso scrivere la nostra implementazione di Observer semplicemente per essere puristi, e la nostra logica dietro questa decisione è che i futuri programmatori professionisti che lavorano con noi a questo progetto hanno una migliore possibilità di capire $ .Deferred di qualche mano- implementazione laminata. Molti sviluppatori, d'altro canto, sostenevano che sarebbero stati esposti a XMLHttpRequest in un dato momento, quindi essere un purista qui sembrava meno rischioso dal punto di vista della comunicazione con altri sviluppatori di ciò che fa un pezzo di codice.
Analisi:
In precedenza, ho menzionato le regole. Abbiamo scritto una serie di "regole" progettate per mantenere il codice mantenibile. Ad esempio, la regola n. 1 è che le manipolazioni del DOM jQuery avvengono solo in un livello "vista". Quindi l'unico jQuery che usiamo negli altri livelli è l'oggetto $ .Deferred e nient'altro.
Usiamo $ .Deferred in tutta l'applicazione per mantenere una certa logica nei livelli a cui appartiene. Ad esempio, manteniamo un osservatore $ .Deferred persistente nei gestori di clic del DOM per "notificare" al controller che si è verificato un evento click in modo che il controller possa delegare altri livelli dell'applicazione per ottenere / impostare, recuperare / archiviare o eseguire altre azioni.
Usando TDD come metodologia di sviluppo, abbiamo creato piccole funzioni, in cui il più grande non è mai più di una pagina e la maggior parte dei livelli ha una grande quantità di copertura di test.
Dopo alcuni mesi, la giuria è ancora fuori se avremmo dovuto usare un framework, in quanto gran parte di ciò che abbiamo fatto potrebbe essere generalizzato ulteriormente in un framework riutilizzabile. Abbiamo imparato un bel po 'a provarlo, e spero che questa esperienza aiuti gli altri che desiderano sviluppare applicazioni lato client che implichino molte operazioni asincrone.
Per dare credito dove è dovuto, ho preso ispirazione dalle seguenti persone:
Per ulteriori informazioni su come andare senza framework, vedi il Zero Framework Manifesto
di Joe Gregorio