Esistono schemi di progettazione per l'associazione dei dati nell'architettura basata su eventi?

Question

Esistono schemi di progettazione per l'associazione dei dati nell'architettura basata su eventi?

#1 da (4 voti)

4

Sviluppo un gioco basato su browser con node.js nella parte posteriore e tela HTML5 nel front-end. Usa WebSockets per la comunicazione.

Il mio piano è quello di generare eventi aziendali sul lato client, ad esempio "finishJob". Il cliente memorizzerà tutte le informazioni pertinenti aggiornate.

non deve chiamare il server ogni volta che ha bisogno di alcuni dati, ad esempio: denaro dei giocatori
per raggiungere questo obiettivo, il cliente si iscriverà al canale giocatori
ogni giocatore online ha il proprio canale, come una chat room
ogni volta che succede qualcosa con un giocatore, il suo canale attiva un evento con nuovi dati dei giocatori

Nel pattern MVC qui il modello è Player, la View è la tela HTML5, ma ho bisogno di 2 tipi di controller:

controller per gestire eventi aziendali
controller per gestire canali e abbonati

Le mie domande: è un'opzione valida? Se sì, esiste un modello di design simile per questo o qualsiasi articolo su questo tipo di architettura? Esistono convenzioni di denominazione ("controller", "gestori", "canali" ...)?

design architecture event-programming websockets

posta blaskov 07.01.2015 - 11:25

fonte

1 risposta

Leggi altre domande sui tag design architecture event-programming websockets

Utilizzo di audit trail come macchina del tempo? Quando è opportuno mappare un DTO alla sua controparte Entità

score 4 · Accepted Answer

Si

... vedi il link sottostante per questo modello ...

Se stai scrivendo un'applicazione che usa Peers - o qualsiasi app complessa che richiede solide Object-Networks io userei un'architettura basata sugli eventi.

Utilizzo di un mediatore o EventHub (Event-Aggrigator)

L'approccio più semplice sarebbe implementare il modello di mediatore progettato da Addy Osmoni .

Questo ti permette di scrivere qualcosa come:

// core.js
mediator.subscribe('newMemberAdded', function newMemberAddedHandler(id){
    this.membersModule.add(id);
});

...

// membersUI.js
$('#addMember').click(function(){
    ...
    mediator.publish('newMemberAdded', 998);
    ...
});

Con questo, l'unico Accoppiamento richiesto dai tuoi moduli è un riferimento a mediator per comunicare con altri moduli.

L'uso di un mediatore è molto potente e renderà i tuoi moduli più alzabili (accoppiamento libero), tuttavia ci sono alcune convenzioni che dovresti prendere in considerazione mentre sviluppi un EDA:

I moduli pubblicano solo interessi - non Query + eventi di comando
- e.g: eventHub.fire ('buttonClicked') NOT eventHub.fire ('get: membersList', function () {...})
Query + Canali di comando Sono riservati all'interazione core / facciate (vedi post di Osmoni)
Risoluzione dei nomi di canale Noun-Verb-Adjective :
- ad esempio 'log' , 'start' , 'change' , 'notice' tutto può essere visto come un comando o qualcosa che è successo. Puoi aggiungere il coniugato ing per ovviare a questo ( 'starting' )
Ascolta prima di parlare! - Altrimenti potresti perdere eventi
Visita il link sopra per ulteriori

Inoltre, puoi vincolare il tuo Mediatore a un WebWorker o SharedWorker per condividere lo stato tra le schede del browser (ecc.) e associare il tuo lavoratore a un EventHub sul tuo server per un accoppiamento ancora più pulito.

So che questo post è un po 'ad hoc, ma spero che sia sufficiente per iniziare!