Organización de Vars de sesión en Scala/Lift

Question

Me gustaría obtener algunas ideas sobre cómo organizar mejor los valores de sesión en una aplicación scala/lift.

He leído a través de una serie de materiales Scala en línea y han encontrado por lo general el siguiente paradigma en todos los ejemplos que introducen sesión de Vars:

1. declarar un objeto que amplía la clase SessionVar
2. poner ese objeto en un archivo que contiene un fragmento (o cualquier archivo)
3. acceso a ese objeto desde cualquier parte del código base (elevación se hará cargo de ciclo de vida de la sesión de var basado en el tiempo de vida de la sesión HTTP del usuario)

Quizás no estoy entendiendo algo, pero me preocupa que este enfoque lleve a un montón de estos objetos en varios archivos por todos lados. No es tan importante si se trata de una aplicación pequeña, pero cuando un proyecto se agranda, esto podría llevar al caos.

Para aquellos que han trabajado en proyectos Scala más grandes, ¿hay un mejor enfoque generalmente aceptado? (incluso si es algo tan simple como poner todos estos objetos en un archivo común?)

Gracias.

Answer 1

Esto es un poco subjetivo, pero lo intentaré. Creo que depende del alcance de la sesión var en tu proyecto.

• Si necesita la sesión var solo en un fragmento, debe convertirlo en un miembro privado de esa clase.
• Si lo necesita en varios fragmentos, pero no en todos, coloque los fragmentos en un paquete y haga que el objeto sea privado para ese paquete. Si tiene muchos de ellos, puede crear un archivo adicional para guardarlos.
• Si lo necesita en todo el mundo, colóquelo en una ubicación central, tal vez dentro de un objeto de paquete.
• Si es posible, evite usar SessionVars por completo.

Answer 2

SessionVars se debe utilizar con moderación en su aplicación. Son similares a las variables de sesión de Servlet, excepto que son de tipo seguro.

¿Cuántas variables de sesión necesita? Personalmente, tengo una variable de sesión para la clave principal del usuario actual y tal vez uno o dos más. El resto del estado de la aplicación debe almacenarse en cierres (porque las funciones asociadas a los GUID se cierran sobre el alcance).