Pattern che impedisce agli eventi di attivarsi

Question

Pattern che impedisce agli eventi di attivarsi

#1 da (1 voti)

0

Sto lavorando alla parte client di un'applicazione web, che è responsabile per ottenere risposte dagli utenti per domande specifiche e archiviarle e ripristinarle dal database (o dai cookie) e sto riscontrando il problema che l'aggiornamento delle risposte dal db attiverà anche il salvataggio di nuovo (perché viene chiamato lo stesso metodo answerQuestion ).

Ecco una semplificazione del mio caso d'uso (coffeescript):

class Questionnaire
  constructor: ->
    @prefillAnswers()
    @listenToInput()
    @listenToQuestionChanges()

  prefillAnswers: ->
    for q in @questionNames
      @answerQuestion getAnswer(q)

  listenToInput: ->
    $('.input').on 'change', (e) =>
      $input = $(e.currentTarget)
      @answerQuestion $input.data('questionName'), $input.val()

  listenToQuestionChanges: ->
    @subscribeToEvent 'answeredQuestion', (msg, data) =>
      saveAnswer(data.question, data.answer)

  getAnswer: (qName) ->
    # fetches answer from a database (such as cookies, but is irrelevant)

  saveAnswer: (qName, answer) ->
    # saves the answer

  answerQuestion: (qName, answer) ->
    @publishEvent 'answeredQuestion', {question: qName, answer: answer} # This part triggers unnecessary saving, but where is the best place for this?
    # Change state of UI and data "model"
    # ...

La mia domanda è, c'è un modello OOP che discute questo problema e le possibili soluzioni? Non so come iniziare ad affrontare questo, e leggere un intero libro non è un'opzione in questo momento ( Lo ho comunque sul mio elenco di cose da fare).

Forse questo potrebbe essere riscritto con un pattern MVC, e mi sto muovendo verso ciò iniziando a leggere il libro Web JavaScript Applicazioni , ma non riesco a vedere al momento anche con MVC, come il mio problema viene evitato nel modo migliore ...

object-oriented design-patterns client-side event-programming coffeescript

posta Cristian 28.07.2014 - 15:13

fonte

1 risposta

Leggi altre domande sui tag object-oriented design-patterns client-side event-programming coffeescript

In un progetto di servizio REST, dove dovremmo inserire il codice che chiama un'API REST di terze parti? alternative N-Tier compatibili con DDD

score 1 · Accepted Answer

Il problema sta nel concetto di answerQuestion . Puoi utilizzare answerQuestion per due ruoli:

Input utente fornito, gli ascoltatori eseguono azioni appropriate.
Aggiornamento del server fornito, i listener eseguono le azioni appropriate.

Approccio semplice

Anche se sono simili, non sono uguali. Lo schema per questo (se vuoi chiamarlo così), dovrebbe avere due metodi separati. Il primo metodo riguarda l'attivazione degli ascoltatori, mentre il secondo dovrebbe inviare la richiesta al server per il salvataggio.

In questo modo, per lo scenario n. 1 quando l'utente fornisce l'input, si chiama non solo il metodo trigger ma anche il metodo save (chiamata esplicita). In questo modo, quando ricevi un aggiornamento del server, puoi semplicemente chiamare il trigger per aggiornare la pagina, senza creare una seconda richiesta.

Bandiera sporca

Un altro approccio potrebbe essere quello di utilizzare il concetto di bandiera sporca, che non fa altro che permettere al client di sapere che è cambiato rispetto alla versione del server. Invece di utilizzare due metodi separati, il tuo answerQuestion eseguirà solo il trigger. Un listener controllerà lo stato del flag dirty e, se è stato modificato, invierà una richiesta di aggiornamento al server. Va da sé che tutte le informazioni provenienti dal server a quel punto avranno il flag dirty impostato su false , quindi anche se il listener riceve l'evento, vedrà che non sono state apportate modifiche e lo ignorerà.

Flag evento

Gli ascoltatori non dovrebbero generalmente preoccuparsi dell'origine dell'evento al fine di essere veramente disaccoppiati, tuttavia potresti fornire informazioni sugli eventi sotto forma di un parametro per fare una distinzione basata su chi lo ha attivato. Tuttavia, potrebbe essere necessario verificare più fonti in questo modo, quindi potrebbe essere preferibile utilizzare semplicemente un valore booleano che indica se è utente in input o attivato dall'utente in qualche modo. Se un altro evento viene attivato di conseguenza, anche tale evento manterrà lo stesso valore per questo flag poiché anch'esso è (o non è) alla fine causato da un utente.

Conclusione

Mentre la bandiera sporca è migliore per i progetti più grandi, non la consiglierei a meno che non ti ritrovi a dover ripetere te stesso più volte per diversi oggetti (diventando così illeggibile). I flag degli eventi possono adattarsi meglio se preferisci l'architettura basata sugli eventi piuttosto che orientata agli oggetti come l'approccio dirty flag.

Spero che questo aiuti.