Come posso mantenere le richieste di servizi Web in un livello DAO senza legare il codice al DOM?

3

Sto lavorando su un'applicazione a singola pagina sulla piattaforma dell'app desktop node-webkit , che significa il 99,9% di tutta la logica è scritta in JavaScript. Poiché si tratta di un riavvio di un progetto su cui stiamo lavorando, ho voluto avvicinarmi all'architettura da un approccio MVC più lato client.

Sto pensando di creare un livello DAO per l'accesso a localStorage, IndexedDB, così come i servizi Web tramite richieste REST. Il problema è che il primo strumento che raggiungo per fare richieste HTTPS al server è jQuery AJAX. Sembra un po 'strano usare jQuery nel livello DAO, anche se non ho intenzione di manipolare il DOM, ma funziona molto bene su node-webkit ed è uno strumento collaudato per recuperare e inviare dati ai server.

Nonostante la popolarità di alcuni framework di applicazioni JavaScript che hanno un certo modo di fare cose, non stiamo pianificando l'utilizzo di framework diversi dalle librerie JavaScript che sono abbastanza leggeri e non invadenti, come jQuery , Underscore, Moustache, moduli Node.js, ma nulla che ci costringa a escludere in modo inequivocabile alcune tecnologie.

Ho intenzione di iniettare jQuery nel livello DAO allo scopo di effettuare chiamate tramite AJAX ai servizi Web. La mia domanda è questa:

  • Come devo affrontare i servizi Web? Tratto i servizi Web come solo un'altra fonte di dati come il database locale?
  • Oppure uso semplicemente l'oggetto raw XMLHttpRequest? Qual è il metodo collaudato per affrontare questo problema di architettura sul lato client, senza framework JavaScript ?
posta jmort253 01.05.2014 - 07:22
fonte

1 risposta

3

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     
risposta data 29.06.2014 - 04:04
fonte