Erlang gen_server vs modulo stateless

Question

Di recente ho finito il libro di Joe e mi è piaciuto molto. Da allora ho iniziato a scrivere un'applicazione soft realtime con erlang e devo dire che sono un po 'confuso dall'uso di gen_server.

Quando dovrei usare gen_server invece di un semplice modulo stateless? Definisco un modulo stateless come segue: - Un modulo che prende il suo stato come parametro (molto simile a ETS / DETS) invece di mantenerlo internamente (come gen_server)

Dire per un modulo tipo gestore fatture, dovrebbe inizializzare e restituire lo stato che poi passerei successivamente ad esso? SomeState = InvoiceManager: Init (), SomeState = InvoiceManager: AddInvoice (SomeState, AnInvoiceFoo).

Supponiamo che avrei bisogno di più istanze dello stato del gestore delle fatture (supponiamo che la mia applicazione gestisca più società ognuna con le proprie fatture), se ognuna avesse un gen_server con stato interno per gestire le proprie fatture o sarebbe meglio semplicemente avere il modulo stateless sopra?

Dov'è la linea tra i due?

(Nota che l'esempio di gestione della fattura sopra è proprio questo, un esempio per illustrare la mia domanda)

Answer 1

Dipende fortemente dalle tue esigenze e dal design dell'applicazione. Quando è necessario uno stato condiviso tra i processi, è necessario utilizzare il processo per mantenere questo stato. Quindi gen_server , gen_fsm o altri gen_ * sono tuoi amici. È possibile evitare questo design quando l'applicazione non è simultanea o questo design non offre altri vantaggi. Ad esempio, interrompere l'applicazione ai processi porterà a una progettazione più semplice. In altri casi a volte puoi scegliere la progettazione di un singolo processo e usare " stateless " moduli per prestazioni o simili. & Quot; stateless " Il modulo è la scelta migliore per compiti semplicemente senza stato (puramente funzionali). gen_server è spesso la scelta migliore per persone che sembrano naturalmente "processare". È necessario utilizzarlo quando si desidera condividere qualcosa tra i processi (l'utilizzo dei processi può essere limitato dalla scalabilità o dalla concorrenza).

Answer 2

Non credo davvero che tu possa fare quella distinzione tra quello che chiami un modulo senza stato e gen_server. In entrambi i casi esiste un ciclo di ricezione ricorsivo che porta lo stato in almeno un argomento. Questo ciclo principale gestisce le richieste, funziona a seconda delle richieste e, se necessario, restituisce i risultati ai richiedenti. Il ciclo principale gestirà molto probabilmente anche una serie di richieste amministrative che potrebbero non far parte dell'API / protocollo principale.

La differenza è che gen_server estrae il ciclo di ricezione principale e consente all'utente di scrivere solo il codice utente . Gestirà anche molte funzioni amministrative OTP per te. La differenza principale è che il codice utente si trova in un altro modulo, il che significa che vedi lo stato passato attraverso più facilmente. A meno che tu non riesca effettivamente a scrivere il tuo codice in un grande ciclo di ricezione e non chiamare altre funzioni per fare il lavoro, non c'è vera differenza.

Quale metodo è migliore dipende molto da ciò di cui hai bisogno. L'uso di gen_server semplifica il tuo codice e ti offre funzionalità aggiuntive " gratuitamente " ma può essere più restrittivo. Arrotolare il tuo ti darà più potenza ma anche più possibilità di rovinare le cose. Probabilmente è anche un po 'più veloce. Di cosa hai bisogno?

Answer 3

Avendo usato entrambi i modelli, devo dire che l'uso del gen_server fornito mi aiuta a rimanere strutturato più facilmente. Immagino sia per questo che è incluso nella pila di strumenti OTP: gen_server è un buon modo per togliere la ripetitiva piastra della caldaia.

Answer 4

Se hai uno stato condiviso su più processi, dovresti probabilmente andare con gen_server e se lo stato è solo locale per un processo, un modulo stateless andrà bene.

Answer 5

Suppongo che le tue fatture (o qualunque cosa rappresentino) dovrebbero essere persistenti, quindi finirebbero comunque in una tabella ETS / Mnesia. In tal caso, è necessario creare un modulo stateless in cui inserire l'API per accedere alla tabella delle fatture.