Sé que la mayoría de las personas recomiendan utilizar HttpRuntime.Cache porque tiene más flexibilidad ... etc. Pero, ¿y si el objeto persiste en la memoria caché durante la vida de la aplicación? ? ¿Hay algún inconveniente importante al usar el objeto Application [] para almacenar en caché las cosas?HttpRuntime.Cache [] vs Application []
Respuesta
Siempre que no abuse del estado de la aplicación, no veo ningún problema en usarlo para los elementos que no desea caducar. Alternativamente, probablemente usaría una variable estática cerca del código que la usa. De esa forma evitas pasar por HttpApplicationState
y luego ser forzado a tener una referencia a System.Web si quiero acceder a mis datos.
Pero asegúrese de pensar en cómo utiliza el objeto (s) que almacena en HttpApplicationState
. Si se trata de un DataSet
al que agrega elementos para cada solicitud, en algún momento termina consumiendo demasiada memoria en el servidor web. Lo mismo podría suceder si continúa agregando elementos al HttpApplicationState
cuando procesa las solicitudes, en algún momento obligará a la aplicación a reiniciarse.
Esa es probablemente la ventaja de usar Cache en su situación. El consumo de grandes cantidades de memoria no es tan fatal porque permite que ASP.NET libere los elementos en su caché cuando la memoria escasea.
Use la caché cuando desee que los elementos caduquen automáticamente o se reclamen cuando la memoria es escasa. De lo contrario, utilice variables estáticas si puede, ya que producirán un mejor rendimiento y luego buscarán en la colección ApplicationState. No estoy exactamente seguro de cuál sería el caso cuando usar ApplicationState, pero seguro que habrá algunos.
La aplicación está en desuso por la memoria caché. Si necesita algo con el alcance de la aplicación, entonces debe crearlo como miembro estático de una clase o usar el Caché. Si desea ir a la ruta de Caché pero no desea que caduque nunca, debe usar la opción CacheItemPriority.NotRemovable cuando inserta el valor en el caché. Tenga en cuenta que es posible utilizar esta prioridad y seguir usando dependencias de caché, por ejemplo, si sus datos dependieron de algo en el sistema de archivos. Todo lo que hace CacheItemPriority es evitar que HttpRuntime.Cache borre de manera inteligente el elemento cuando siente la presión de la memoria y usa su algoritmo de Mínimo uso recientemente para purgar elementos que no están viendo mucho uso.
- 1. HttpContext.Current.Cache vs. HttpRuntime.Cache
- 2. Tiggr vs Application Craft
- 3. Application vs Container Managed EntityManager
- 4. ¿Debo usar HttpRuntime.Cache?
- 5. Prácticas recomendadas de HttpRuntime.Cache
- 6. log4net vs MS Logging Application Block
- 7. Application vs Cache: Mecanismo de bloqueo
- 8. Qt Application Performance vs. WinAPI/MFC/WTL/
- 9. Uso de Application Id Generator vs. Database Id Generator
- 10. Entity Framework 4.1 vs Enterprise Data Application Block Rendimiento máximo
- 11. Jersey JAX-RS + Spring application application sample
- 12. Application Publisher
- 13. ¿Está bien utilizar HttpRuntime.Cache fuera de las aplicaciones ASP.NET?
- 14. ¿Cómo puedo obtener el tamaño de un objeto en HttpRuntime.Cache?
- 15. Lea el elemento HttpRuntime.Cache como de solo lectura
- 16. ¿Cuál es la diferencia entre HttpRuntime.Cache y Session?
- 17. ¿Es posible compartir HttpRuntime.Cache entre varios servidores web?
- 18. Longitud máxima de claves de caché en el objeto HttpRuntime.Cache?
- 19. ¿Cuál es la serialización predeterminada utilizada por ASP.net HttpRuntime.Cache
- 20. Qt Console Application Tutorial?
- 21. iTunes Application Loader - automatización
- 22. .NET Newsletter Application
- 23. android application object
- 24. WPF C# Application Performance
- 25. Honeycomb Gmail Like Application
- 26. Android Tablet Application - ActionBar
- 27. Bing Application ID
- 28. Android Application APK signing?
- 29. Application-Integrated "Send Feedback"
- 30. nHibernate + Mvc3 Sample Application
¿Por qué dices que la aplicación está obsoleta? Nunca he visto esto en ninguna parte y no está indicado en la documentación. –
Porque todo lo que puede hacer, la memoria caché puede hacerlo mejor. No hay ninguna razón para que la aplicación exista ahora que existe la memoria caché, excepto por la compatibilidad con versiones anteriores. – ssmith
Otra pequeña razón para preferir la caché a la aplicación es que si los datos son del todo sensibles, la caché es (ligeramente) más segura. El razonamiento aquí es que los contenidos de la Aplicación siempre se muestran de forma predeterminada cuando el Rastreo de ASP.NET está activado, ya sea a nivel de página o a través de Trace.axd. Dado que esto podría suceder por accidente, sería fácil revelar cualquier cosa sensible en la aplicación públicamente. El contenido de la caché no se muestra en la salida de Trace. – ssmith