Deseamos regalarte la mejor solución que descubrimos en línea. Queremos que te resulte de utilidad y si deseas compartir algún detalle que nos pueda ayudar a mejorar hazlo con libertad.
Solución:
Lo que realmente haces es almacenamiento en caché, y es genial, ya que reduce las llamadas a un almacenamiento externo (una base de datos o un archivo, lo que sea). La compensación es el uso de la memoria, por supuesto. Ahora, casi cualquier marco web moderno, incluido ASP.NET, incluye algún tipo de mecanismo de almacenamiento en caché. O lo usa, o usa algún tipo de variable global.
Almacenamiento de datos en ASP.NET integrado Cache El objeto tiene algunas ventajas significativas, ya que este mecanismo realmente verifica el uso de la memoria y elimina los datos almacenados en caché de acuerdo con algunas reglas.
Sin embargo, si los datos que desea almacenar en caché se utilizan de forma intensiva en toda la aplicación y su tamaño no es demasiado grande (por ejemplo, menos de 1 MB), es posible que desee almacenarlos como una variable global.
En ASP.NET, las variables globales se logran usando el Application objeto, como usted describió en su pregunta, o escribiendo público static propiedades/campos en una clase interna/pública.
Aquí está mi solución para static propiedades. Tenga en cuenta que uso un objeto de bloqueo para proteger los datos internos de la corrupción. Se parece a esto:
public class WhateverClass
private static object theLocker = new object();
private static YourDataType theData;
public static YourDataType TheData
get
lock (theLocker)
return theData;
set
lock (theLocker)
theData = value;
El uso es muy simple:
Primera vez, en Application_Start:
protected void Application_Start()
RegisterRoutes(RouteTable.Routes);
WhateverClass.TheData = loadDataFromSql();
En cualquier controlador:
var myData = WhateverClass.TheData;
Este enfoque es mejor porque tiene seguridad de tipo, ya que este público static La propiedad se puede declarar explícitamente con el tipo exacto. Además, este tipo de almacenamiento es más comprobable ya que no depende del contexto web.
HTH!
HttpContext.Current.Application es esencialmente una resaca que se necesita para la compatibilidad con ASP clásico. Es esencialmente un static Hashtable con semántica de bloqueo ASP clásica (Application.Lock / Application.UnLock).
Como una tabla Hash de tipado débil, deberá lanzar los objetos que recupere:
MyObject myObject = (MyObject) HttpContext.Current.Application["myObject"];
En una aplicación ASP.NET que no es una migración de ASP clásico, preferiría usar otras cosas estándar de .NET, como:
-
UN static campo, usando la semántica de bloqueo de .NET si necesita bloquear (por ejemplo, la palabra clave de bloqueo de C# o una instancia de ReaderWriterLockSlim, según sus requisitos):
static MiObjeto miObjeto = LoadFromSql();
-
El caché de ASP.NET, que tiene una rica funcionalidad para administrar la caducidad, las dependencias,…
si, usando HttpContext.Current.Application funcionará bien para lo que estás haciendo. No hay problemas.
HttpContext.Current.Application es simplemente una referencia a la static global HttpApplicationState objeto en .NET para su aplicación web, de los cuales debe haber una instancia global por aplicación web. Al almacenar datos allí, proporciona un acceso rápido y seguro para subprocesos a sus variables globales. Asegúrese de bloquearlos cuando actualice los valores, como en este ejemplo:
System.Web.HttpContext.Current.Application.Lock();
System.Web.HttpContext.Current.Application["WebApplicationPath"] = MyWebApplicationPath;
System.Web.HttpContext.Current.Application.UnLock();
Como han mencionado otros, también puede crear una serie de static clases en tu App_Code u otra carpeta y allí almacenar global static valores, así como su HttpContext.Current.Application valores, donde se pueden verificar de forma segura para obtener valores o actualizarse desde la base de datos, o actualizarse y verificarse entre sí, trabajando en conjunto. Yo suelo crear un static clase global para ayudar en la gestión y recuperación de las variables de aplicación que almaceno. De esta manera tienes tanto el diccionario estatal de la HttpApplicationState clase y la aplicación web static objetos trabajando juntos para compartir y mantener valores globales. (Tenga en cuenta cada static la clase se asigna por proceso de trabajo y puede haber hasta 10 WP en promedio de forma predeterminada en muchos servidores web/aplicaciones web de IIS. Así que mantén los datos en static tipos al mínimo).
Tenga en cuenta que algunas granjas de servidores mencionadas no comparten el estado de la aplicación. Hay muchas maneras de manejar esto. No soy un fanático del caché debido a las formas en que puede caducar, fallar, volverse obsoleto o corromperse. Una solución más simple es simplemente usar la base de datos y las cadenas de consulta de URL para comunicarse entre servidores y mantener el estado. ¡Buena suerte!