Pregunta

Estoy empezando a portar una aplicación a ASP.net MVC y tengo un objeto que mantiene el estado de la aplicación (hace un seguimiento de ciertos procesos que se ejecutan en la máquina, arranca y se detiene según sea necesario y envía / recibe un mensaje MSMQ).

¿Dónde debo guardar este objeto? En mi aplicación actual (basada en HttpListener) es un singleton, sin embargo, sé que los singletons hacen que las pruebas sean difíciles. Sería difícil burlarse o probar este objeto, al menos en el contexto de la propia aplicación MVC, y tiene su propio conjunto de pruebas fuera de la aplicación de todos modos. Sin embargo, es posible que deba ser reemplazado por un talón para la prueba.

El objeto debe estar disponible para varios controladores. ¿Dónde debo almacenar este objeto y cómo debo ponerlo a disposición de los controladores? Nunca he visto un caso como este descrito en ningún ejemplo de ASP.net MVC que he visto.

ACTUALIZACIÓN:

Supongo que necesito explicar por qué no puedo almacenar estos datos en una base de datos. Primero debo explicar lo que hace la aplicación:

La aplicación sirve imágenes que son generadas dinámicamente por varios motores " ;, que son procesos que se ejecutan en el servidor, comunicados a través de MSMQ. Vamos a llamar al objeto que estoy haciendo la pregunta sobre el EngineManager. El proceso es algo como esto:

  1. El cliente envía una solicitud XML al servidor, dando el nombre de " motor " para ser utilizado, así como una serie de parámetros que describen la imagen.
  2. La aplicación comprueba el EngineManager para ver si ese motor se está ejecutando. Si no, se inicia.
  3. La aplicación publica un mensaje MSMQ en el motor y espera la respuesta.
  4. La aplicación envía la imagen generada al cliente.
  5. Si en algún punto el motor se apaga o se bloquea, la aplicación debe ser consciente de ello para que pueda reiniciarse en la próxima solicitud a ese motor.
  6. Cuando la aplicación se apaga, todos los motores también se apagan.

Hay varios controladores que manejan estas solicitudes, y cada uno realiza un trabajo ligeramente diferente. Todos ellos deben comunicarse con el mismo EngineManager, como también debe hacerlo, en ciertas situaciones, sincronizar el acceso a otros recursos.

Como puede ver, no es su servidor web típico respaldado por bases de datos.

¿Fue útil?

Solución

Si desea que este objeto esté disponible para todos los usuarios, es decir, no es específico de la sesión, puede ver cómo almacenarlo en el estado de la aplicación:

http://msdn.microsoft.com/ en-us / library / bf9xhdz4 (VS.71) .aspx

Sin embargo, el estado de la aplicación tiene varias desventajas, como se indica en la página enlazada arriba, así que asegúrese de que estos problemas no le afecten antes de seguir esa ruta. En general, evito el estado de aplicación y almaceno los datos de la aplicación en una base de datos backend. Como no desea bajar esta ruta, el estado de la aplicación puede estar bien para usted.

Otros consejos

Debe pasar el objeto al constructor de cada instancia de Controller , y los métodos de acción del controlador deben utilizar la instancia de objeto que se pasa al constructor de la instancia de Controller . / p>

El ControllerFactory predeterminado que se envía con ASP.NET MVC no le permitirá hacer esto. Sin embargo, hay marcos complementarios gratuitos (el que me gusta es Autofac) que permiten este estilo de programación.

Mantenga los datos de su aplicación en la base de datos y acceda a esto por capa de modelo. Cliente solo mantiene la identificación de sesión.

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