Práctica recomendada para almacenar objetos requeridos a nivel mundial en GWT

Estoy empezando a desarrollar una aplicación GWT en estilo MVP (GWTP) y que utiliza seguridad Spring para autenticación y autorización en el servidor.Práctica recomendada para almacenar objetos requeridos a nivel mundial en GWT

En muchas vistas de la aplicación, tengo que habilitar o deshabilitar los controles con respecto a una autorización otorgada por el usuario actual. Ya tengo un servicio RPC que proporciona acceso a un userDetailsDto que contiene toda la información necesaria.

Ahora mi pregunta: ¿Cuál es el mejor lugar para almacenar al usuario DTO en el lado del cliente?

Dado que los derechos del usuario son relevantes en muchos presentadores, tendría que pasarlo por todas partes. Alternativamente, podría establecer una instancia de servicio RPC en cada presentador y volver a solicitar los detalles del usuario (probablemente en caché en el lado del cliente). Pero no me gusta la idea de tener un servicio RPC de usuario en cada presentador solo para este propósito.

Para ser honesto, prefiero un registro central donde poner el objeto UserDetails y que sea accesible desde cualquier lugar de mi aplicación. ¿Ya existe un registro de este tipo en GWT?

Como en mi ejemplo, a menudo puede verse confrontado con objetos usados horizontalmente. ¿Cómo lidiar con ellos en GWT?

Fuente

2012-01-24 rainer198

Simplemente almacene su usuario actual en una variable estática pública. Será accesible desde cualquier lugar.

Fuente

2012-01-24 15:37:29 koma

Esa es mi solución actual, de hecho. Sin embargo, 1) las variables estáticas son problemáticas cuando se trata de pruebas unitarias y 2) es difícil decidir qué parte (clase) es responsable de mantener esa instancia estática. Un presentador, el servicio RPC (significaría que tengo una dependencia del servicio RPC en mi objeto de vista si deseo acceder al objeto del usuario desde allí. – rainer198

Guardo mi usuario actual en la implementación de ClientFactory, simple y fiel a KISS principio (http://en.wikipedia.org/wiki/KISS_principle) – koma

Aunque estoy usando GIN en lugar de la fábrica del cliente, me gusta esta solución. Está claro que esta pregunta no puede tener una sola respuesta verdadera (stackoverflow incluso me advirtió que podría ser rechazado), entonces, Riley Lark, si pudiera marcar ambas respuestas como "correctas", lo haría ;-) – rainer198

Inyecto un objeto "AppState" en todos los presentadores que necesitan saber cosas como los derechos del usuario conectado, sus preferencias, etc. Prefiero la inyección a una variable estática pública porque se siente más controlada, es Es más fácil burlarse de las pruebas, y la mecanografía extra me obliga a considerar si cada objeto realmente necesita acceso a los datos globales.

Fuente

2012-01-24 15:57:06

¿Quiere decir, por inyección, pasarlo al constructor del presentador con la anotación @Inject de GIN? – rainer198

En realidad, solo se lo paso al constructor con argumentos simples en la definición del constructor. No es tanto el tipeo extra, y me gusta el comportamiento cuando cambio algo: compilar errores en cada punto que necesita cambiar. Causa consideración en todos los puntos correctos, en mi humilde opinión. –

Práctica recomendada para almacenar objetos requeridos a nivel mundial en GWT

Respuesta

Cuestiones relacionadas