Recomendaciones sobre la estrategia de acceso a datos Web

Cuando se diseña un acceso a datos en la aplicación Web se deben hacer varias elecciones sobre el modo de comunicarse con un origen de datos, acerca de si se van a almacenar los datos entre las acciones de ida y vuelta de la página, y en caso afirmativo, en qué lugar. Las elecciones realizadas pueden determinar con qué eficacia se ejecutará y escalará la aplicación. No existe ninguna estrategia de acceso a datos conveniente para todas las situaciones. De hecho, cada opción tiene su propias ventajas y desventajas, que se deben comprender.

Las secciones siguientes muestran detalladamente las opciones de diseño básicas que se deben realizar para el acceso a datos en formularios Web Forms. Las opciones se presentan aquí en una secuencia; pero cada opción se basa en una realizada previamente.

¿Conjunto de datos o acceso directo y lector de datos?

Es una opción fundamental decidir si se desea almacenar registros en caché en un conjunto de datos o si se desea una acceso directo a la base de datos y leer los registros mediante un lector de datos. En algunas operaciones de base de datos, como la creación y edición de estructuras de base de datos, no se puede utilizar un conjunto de datos. Por ejemplo, si se desea crear una nueva tabla de base de datos desde la aplicación, no se puede hacer con un conjunto de datos; en vez de ello, se podría ejecutar un comando de datos. No obstante, en escenarios de acceso a datos generales, se puede optar entre almacenar registros en un conjunto de datos desconectado y trabajar directamente con la base de datos utilizando comandos de datos.

Nota   Para obtener información detallada acerca de los conjuntos de datos, vea Introducción a los conjuntos de datos. Para obtener información detallada sobre el acceso a la base de datos de forma directa, vea Introducción a los objetos DataCommand en Visual Studio.

Cada estrategia tiene ventajas inherentes que se aplican a cualquier escenario de acceso a datos, no sólo a las páginas de formularios Web Forms. Por ejemplo, los conjuntos de datos facilitan el trabajo con tablas relacionadas y con datos de orígenes dispares. Por otro lado, usar un lector de datos produce a menudo un rendimiento y una utilización de la memoria ligeramente superiores, elimina el paso adicional (y la necesidad de más memoria) de rellenar un conjunto de datos y ofrece un control más directo sobre las instrucciones o los procedimientos almacenados utilizados. Para obtener información detallada sobre las ventajas comparativas de cada uno de estos enfoques en general, vea Recomendaciones sobre estrategias de acceso a datos.

Conjuntos de datos y comandos de datos en las páginas de formularios Web Forms

Cuando se trabaja con páginas de formularios Web Forms, entran en juego factores adicionales a la hora de decidir entre usar un conjunto de datos o un lector de datos. Un factor significativo es el ciclo de vida de la página: las páginas de formularios Web Forms se inicializan, se procesan y, a continuación, se descartan con cada acción de ida y vuelta. Si simplemente se desea mostrar datos en una página, crear un conjunto de datos, rellenarlo y, a continuación, enlazar controles con él puede representar un trabajo innecesario, ya que el conjunto de datos será descartado inmediatamente. En muchos casos, resulta más eficaz usar un lector de datos para obtener la información y después enlazar controles con ella en tiempo de ejecución.

Sugerencia   Cualquiera que sea el método que se decida usar para obtener los datos del origen, se deberá siempre intentar minimizar la cantidad de información usada en una página, ya que cuantos más datos devuelva una consulta o un procedimiento almacenado, más recursos del servidor se usarán.

Por lo tanto, se puede decir que, en general, en las páginas de formularios Web Forms es mejor usar comandos de datos para ejecutar instrucciones SQL o procedimientos almacenados, usando un lector de datos para obtener éstos. Por ejemplo, para mostrar información en un comando DataList, puede ejecutarse una instrucción SQL y después enlazar el control con un lector de datos. Como excepciones a esta regla general se pueden citar las siguientes:

• Trabajar con tablas relacionadas   Los conjuntos de datos permiten mantener varias tablas relacionadas y facilitar compatibilidad con las relaciones y la integridad referencial. El trabajo con registros relacionados, por ejemplo, la lectura de registros primarios y sus correspondientes secundarios, puede resultar mucho más sencilla en un conjunto de datos que la obtención de registros de forma independiente cuando se ejecutan comandos en una base de datos.
• Intercambiar datos con otros procesos   Si la página de formularios Web Forms obtiene los datos de otro componente, tal como un servicio XML Web, casi siempre se usará un conjunto de datos para albergar la copia local de los datos. Los conjuntos de datos leen y escriben automáticamente la secuencia XML utilizada para comunicarse entre los componentes de .NET Framework.
• Trabajar con un conjunto estático de registros   Si se precisa utilizar el mismo conjunto de registros asiduamente, por ejemplo, cuando los usuarios están paginando en una cuadrícula, puede resultar eficaz rellenar dichos registros en un conjunto de datos en lugar de volver al origen de datos en cada acción de ida y vuelta. Esto ocurre especialmente cuando se desea reservar un conjunto concreto de registros en una base de datos que varía con frecuencia.

Una ventaja más general de la utilización de los conjuntos de datos es que resultan más sencillos de programar que trabajar directamente con comandos de datos. Sin embargo, se deberá calibrar esta ventaja cuidadosamente con respecto a otros requisitos de la aplicación.

Para obtener información detallada sobre el uso de comandos de datos, vea Introducción a los objetos DataCommand en Visual Studio.

¿Guardar los conjuntos de datos o volver a crearlos en cada ocasión?

Si se utiliza un conjunto de datos, la próxima elección posible es decidir si se desea volver a crearlo con cada acción de ida y vuelta. Existen dos opciones:

• Crear una instancia del conjunto de datos y rellenarla cada vez que se procese la página. Una vez que haya finalizado el procesamiento de la página y que ésta se haya enviado al explorador, el conjunto de datos será descartado.
• Crear y rellenar el conjunto de datos una vez, normalmente la primera vez que se ejecuta la página. A continuación, guardar el conjunto de datos de modo que se pueda recuperar con cada acción de ida y vuelta subsiguiente.

Crear el conjunto de datos cada vez significa que con cada acción de ida y vuelta, de hecho, cada vez que el usuario haga clic en un botón de la página, se ejecutará una consulta o procedimiento almacenado en el origen de datos. Por ejemplo, si se tiene una página de formularios Web Forms en la que el usuario desea recorrer los datos y el conjunto de datos se crea cada vez, la página de formularios Web Forms ejecutará una consulta en el origen de datos para obtener el siguiente conjunto de registros que debe mostrar.

Sugerencia   Recuerde siempre minimizar la transferencia de datos. Cuando resulte práctico, use criterios de selección para reducir el número de registros que precisa en una página.

Si, por otro lado, se guarda y restablece el conjunto de datos, no se precisará volver al origen sólo para obtener unos pocos registros más. Sin embargo, guardar el conjunto de datos conlleva una serie de inconvenientes. Uno importante consiste en que el conjunto de datos consume memoria durante la ejecución de las acciones de ida y vuelta. Si, por ejemplo, un conjunto de datos es muy grande, puede usar una considerable cantidad de memoria del servidor para almacenarse, y si varios usuarios crean conjuntos de datos grandes, se puede consumir rápidamente la memoria disponible en el servidor. Una opción es almacenar los datos en la página; para obtener más información, vea la sección siguiente.

Otra desventaja posible es que el conjunto de datos puede perder la sincronización con el origen de datos, ya que no se actualiza cada vez que el usuario hace clic en un botón. Si se trabaja con datos de alta volatilidad (datos de inventario, por ejemplo), probablemente resultará más conveniente que la aplicación vuelva a crear el conjunto de datos con cada acción de ida y vuelta.

¿Caché en el servidor o en el cliente?

Si se decide guardar el conjunto de datos después de cada acción de ida y vuelta, se debe elegir dónde guardarlo. Este punto constituye la principal preocupación en el mantenimiento de estados de las páginas de formularios Web Forms: ¿dónde se almacena la información que se desea conservar entre las acciones de ida y vuelta? Para obtener información sobre el almacenamiento de valores, vea Administración del estado de los formularios Web Forms.

Existen dos opciones:

• En el servidor: guardar el conjunto de datos en estado de sesión, estado de aplicación o usando una caché.
• En el cliente, es decir, en la página: guardar el conjunto de datos usando el estado de vista o ubicando los datos en un campo oculto propio. El estado de vista también se implementa mediante un campo oculto.

Almacenar el conjunto de datos en el servidor utiliza recursos del servidor. Si se almacenan demasiados datos (un gran conjunto de datos o muchos usuarios que almacenen pequeños conjuntos de datos), se puede afectar al rendimiento y a la escalabilidad del servidor. Mediante una caché se puede evitar parcialmente este problema, ya que el administrador de caché descartará el conjunto de datos si el servidor precisa memoria o si la fecha de almacenamiento en la caché ha vencido. Sin embargo, debido a que no existe ninguna garantía de que el conjunto de datos permanezca en la caché, se deberá agregar lógica a la página para que compruebe si el conjunto de datos está disponible en la caché o no; si no lo está, se deberá volver a crear, y ubicar una copia de nuevo en la caché.

Almacenar los datos en la página implica que no se utilizarán recursos del servidor para guardar los datos. No obstante, los datos se convierten en parte de la secuencia HTML de la página, por lo que, si el conjunto de datos es grande, puede afectar en gran medida al tiempo que tarda en cargarse la página en el explorador de los usuarios y en exponerse de vuelta al servidor. Para obtener información detallada sobre el almacenamiento de datos en estado de vista, vea Guardar los valores de las páginas de formularios Web Forms mediante ViewState.

Sugerencia   Intente mantener siempre el tamaño de un conjunto de datos al mínimo rellenándolo sólo con los registros que precise.

Se almacene el conjunto de datos donde se almacene, se deberá agregar lógica a la página para guardarlo y restablecerlo en el momento apropiado. El ejemplo siguiente muestra un modo típico de almacenar y restablecer un conjunto de datos en estado de sesión. El conjunto de datosdsCustomers1es una instancia de la clase de conjunto de datos dsCustomers. Observe que el conjunto de datos se ha almacenado en estado de sesión con el tipo Object. Cuando se restablezca el conjunto de datos del estado de sesión, se deberá convertir del tipo Object de nuevo en una clase de conjunto de datos.

'Visual Basic
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
   If Page.IsPostBack Then
      dsCustomers1 = CType(Session("myDsCustomers"), dsCustomers)
   Else
      If Session("myDsCustomers") Is Nothing Then
         OleDbDataAdapter1.Fill(dsCustomers1)
         Session("myDsCustomers") = dsCustomers1
      End If
   End If
End Sub

//C#
private void Page_Load(object sender, System.EventArgs e)
{
   // Put user code to initialize the page here
    if (Page.IsPostBack) 
    {
        dsCustomers1 = (dsCustomers) Session["myDsCustomers"];
    }
    else
    {
        if (Session["myDsCustomers"] == null) 
        {
            oleDbDataAdapter1.Fill(dsCustomers1);
            Session["myDsCustomers"] = dsCustomers1;
        }
    }
}

Vea también

Administración del estado de los formularios Web Forms | Almacenar en caché datos de la aplicación | Introducción a las aplicaciones distribuidas y a la integración de datos | Introducción al acceso a datos en las páginas de formularios Web Forms | Seguridad en aplicaciones Web de ASP.NET