Pregunta

Recientemente he terminado el libro de Joe y lo he disfrutado bastante. Desde entonces comencé a codificar una aplicación suave en tiempo real con erlang y debo decir que estoy un poco confundido con el uso de gen_server.

¿Cuándo debo usar gen_server en lugar de un simple módulo sin estado? Defino un módulo sin estado de la siguiente manera: - Un módulo que toma su estado como parámetro (como ETS / DETS) en lugar de mantenerlo internamente (como gen_server)

Diga para un módulo de tipo de administrador de facturas, ¿debería inicializarse y devolver el estado que luego le pasaría a él? SomeState = InvoiceManager: Init (), SomeState = InvoiceManager: AddInvoice (SomeState, AnInvoiceFoo).

Supongamos que necesitaría varias instancias del estado del administrador de facturas (por ejemplo, mi aplicación gestiona varias compañías, cada una con sus propias facturas), en caso de que cada una tenga un gen_server con estado interno para administrar sus facturas o si fuera más conveniente El módulo sin estado arriba?

¿Dónde está la línea entre los dos?

(Tenga en cuenta que el ejemplo anterior de administración de facturas es solo eso, un ejemplo para ilustrar mi pregunta)

¿Fue útil?

Solución

Depende en gran medida de sus necesidades y diseño de la aplicación. Cuando necesita un estado compartido entre procesos, debe utilizar el proceso para mantener este estado. Entonces gen_server , gen_fsm u otro gen_ * es tu amigo. Puede evitar este diseño cuando su aplicación no es concurrente o este diseño no le brinda otros beneficios. Por ejemplo, romper su aplicación a los procesos llevará a un diseño más simple. En otros casos, a veces puede elegir un diseño de proceso único y usar " sin estado " Módulos de rendimiento o similares. " sin estado " módulo es la mejor opción para tareas muy simples sin estado (puramente funcionales). gen_server es a menudo la mejor opción para pensamientos que parecen naturalmente "proceso". Debe usarlo cuando desee compartir algo entre procesos (el uso de procesos puede verse limitado por la escalabilidad o la concurrencia).

Otros consejos

Realmente no creo que puedas hacer esa distinción entre lo que llamas un módulo sin estado y gen_server. En ambos casos, hay un bucle de recepción recursivo que lleva el estado en al menos un argumento. Este bucle principal maneja las solicitudes, funciona dependiendo de las solicitudes y, cuando es necesario, envía los resultados a los solicitantes. Lo más probable es que el bucle principal también maneje una serie de solicitudes administrativas que pueden no formar parte de la API / protocolo principal.

La diferencia es que gen_server separa el bucle principal de recepción y le permite al usuario escribir solo el código de usuario real. También manejará muchas funciones administrativas de OTP para usted. La principal diferencia es que el código de usuario se encuentra en otro módulo, lo que significa que usted ve el estado que se pasa más fácilmente. A menos que realmente logres escribir tu código en un gran bucle de recepción y no llamar a otras funciones para hacer el trabajo, no hay ninguna diferencia real.

Qué método es mejor depende mucho de lo que necesites. El uso de gen_server simplificará su código y le dará una funcionalidad adicional " gratis " Pero puede ser más restrictivo. Rodar el tuyo te dará más poder, pero también te dará más posibilidades para arruinar las cosas. Probablemente sea un poco más rápido también. ¿Qué necesitas?

Habiendo usado ambos modelos, debo decir que usar el gen_server provisto me ayuda a estructurarme más fácilmente. Supongo que esta es la razón por la que se incluye en la pila de herramientas OTP: gen_server es una buena manera de quitar la placa de la caldera repetitiva.

Si ha compartido el estado en varios procesos, probablemente debería ir con gen_server y si el estado es solo local a un proceso, un módulo sin estado funcionará bien.

Supongo que sus facturas (o lo que sea que representan) deberían ser persistentes, por lo que terminarían en una tabla ETS / Mnesia de todos modos. Si esto es así, debe crear un módulo sin estado en el que coloque su API para acceder a la tabla de facturas.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top