2010-05-19 13 views
5

Entiendo que cada actualización de página, especialmente en 'AjaxLand', hace que mi clase back-end/code-back sea llamada desde cero ... Esto es un problema porque mi class (que es un objeto miembro en System.Web.UI.Page) contiene MUCHOS datos que obtiene de una base de datos. Entonces, cada actualización de página en AjaxLand me está causando hacer grandes llamadas a bases de datos en el back-end, en lugar de solo reutilizar un objeto de clase desde la memoria. ¿Alguna solución para esto? ¿Es aquí donde las variables de sesión entran en juego? ¿Son las variables de sesión la única opción que tengo para retener un objeto en la memoria que está vinculado a una instancia de usuario único y sesión única?'Caché' de una tabla grande en ASP.NET

+0

Cada actualización de página causará que la página sea (re) evaluada, independientemente de si se está utilizando AJAX. Su código AJAX NO debería estar refrescando toda la página, debería volver a utilizar los datos relevantes * en el lado del cliente * (es decir, NO como un objeto .NET en la memoria [servidor]). –

Respuesta

1

Eche un vistazo a esta MS article en varios mecanismos de almacenamiento en caché para ASP.NET. Hay una sección llamada "Caché de objetos arbitrarios en la memoria del servidor" que puede interesarle.

0

Ya que mencionas Ajax, creo que es posible que desee considerar los siguientes puntos:

asumir esta gran conjunto de datos es estático y no transitoria, en la primera llamada a Ajax, su aplicación consulta la base de datos, recupera un montón de datos y devuelve al cliente (es decir, el navegador/JavaScript que se ejecuta en el navegador, etc.), el cliente ya tiene todo eso en la memoria. Posteriormente, no es necesario volver al servidor para obtener los mismos datos que su cliente ya tiene en la memoria. Lo que necesita hacer es usar JavaScript para reconstruir el DOM o lo que sea. Todo se puede hacer en el cliente a partir de ahora.

Supongamos ahora que los datos no son estáticos sino transitorios, el almacenamiento en caché en el servidor al colocarlos es que la sesión no será la solución que desea de todos modos. Cada vez que su cliente envía una solicitud al servidor y el servidor simplemente devuelve lo que está en la memoria caché (sesión), los datos ya están obsoletos y no hay diferencia con los datos que el cliente ya tiene en la memoria.

El punto es si los datos son estáticos, guarde viajes redondos al servidor una vez que ya tenga datos en la memoria. Si los datos son transitorios, me temo que no hay una solución económica, excepto volver a consultar o volver a recuperar los datos de alguna manera, y enviar todo de vuelta al cliente.

2

Si sus datos son específicos del usuario, entonces Session sería el camino a seguir. Tenga cuidado si tiene una granja web o un jardín web. En ese caso, necesitará un servidor de sesión o una base de datos para su sesión.

Si sus datos son de nivel de aplicación, entonces Application Data Cache podría ser el camino a seguir. Tenga cuidado si tiene RAM limitada y sus datos son enormes. El caché puede vaciarse en un momento inoportuno.

De cualquier forma, tendrá que probar el rendimiento de su aplicación con los cambios. Incluso puede encontrar que volver a la base de datos es la opción menos mala.

Además, podría echarle un vistazo a Lazy Loading algunos de los datos, para hacerlo menos pesado.

Cuestiones relacionadas