Recomendaciones sobre la estrategia de acceso a datos

Artículo
10/07/2008

Actualización: noviembre 2007

En ADO.NET se supone que hay un modelo de acceso a datos en el que se puede abrir una conexión, obtener datos o realizar una operación y cerrar luego la conexión. ADO.NET proporciona dos estrategias básicas de trabajo con este modelo. Una de ellas consiste en almacenar datos en un conjunto de datos, que es una caché almacenada en memoria de los registros con los que se puede trabajar mientras se está desconectado del origen de datos. Para usar un conjunto de datos, se crea una instancia del mismo y, a continuación, se usa un adaptador de datos para rellenarlo desde el origen de datos. Posteriormente, se trabaja con los datos del conjunto de datos, por ejemplo, enlazando controles con los miembros de dicho conjunto. Para obtener más información, vea Información general sobre conjuntos de datos en Visual Studio.

Una estrategia alternativa consiste en realizar operaciones directamente en la base de datos. En este modelo, se usa una consulta de TableAdapter o un comando de datos que incluye una instrucción SQL o una referencia a un procedimiento almacenado. A continuación, se puede ejecutar la consulta para realizar la operación. Para obtener más información, vea Buscar datos en la aplicación.

Almacenar datos en conjuntos de datos

Un modelo común para tener acceso a datos en aplicaciones de Visual Studio es almacenar datos en conjuntos de datos y usar TableAdapters o adaptadores de datos para leer y escribir la información en la base de datos. Las ventajas del modelo de conjunto de datos son:

**Trabajar con varias tablas **Un conjunto de datos puede contener varias tablas de resultados, que se mantienen como objetos discretos. Puede trabajar con las tablas individualmente o navegar por ellas como tablas primarias y secundarias.
**Manipular datos de varios orígenes **Las tablas de un conjunto de datos pueden representar datos de varios orígenes distintos (por ejemplo, de diferentes bases de datos, archivos XML, hojas de cálculo, etc., todos en el mismo conjunto de datos). Una vez que los datos se encuentran en el conjunto de datos, puede manipularlos y relacionarlos en un formato homogéneo como si vinieran de un único origen.
**Mover datos entre niveles en una aplicación distribuida **Al mantener los datos en un conjunto de datos, puede moverlos fácilmente entre el nivel de presentación, el nivel comercial y el nivel de datos de las aplicaciones.
**Intercambio de datos con otras aplicaciones **Un conjunto de datos proporciona una manera eficaz para intercambiar datos con otros componentes de la aplicación y con otras aplicaciones. Los conjuntos de datos incluyen compatibilidad ampliada para funciones como la serialización de datos en XML y la lectura y escritura de esquemas XML.
**Enlazar datos **Si está trabajando con formularios, normalmente es más fácil enlazar controles a datos en un conjunto de datos que cargar mediante programación los valores de los datos en el control después de ejecutar un comando.
**Mantener registros para su nueva utilización **Un conjunto de datos permite trabajar con los mismos registros repetidas veces sin necesidad de consultar la base de datos. Usando las funciones de los conjuntos de datos, se pueden filtrar y ordenar los registros, y se puede usar un conjunto de datos como origen de datos si se está paginando.
**Fácil de programar **Cuando trabaja con un conjunto de datos, puede generar un archivo de clase que represente su estructura como objetos (por ejemplo, es posible tener acceso a una tabla Customers del conjunto de datos como el objeto dataset.Customers). Esto hace la programación más fácil, clara y con menor probabilidad de error, y es compatible con herramientas de Visual Studio como IntelliSense, el Asistente para la configuración del adaptador de datos, etc.

Realizar operaciones de base de datos directamente

Como alternativa, se puede interactuar directamente con la base de datos. En este modelo, se usa un objeto de comandos de datos que incluye una instrucción SQL o una referencia a un procedimiento almacenado. A continuación, se puede ejecutar el comando para realizar la operación. Para obtener más información, vea Comandos y parámetros (ADO.NET).

Nota de seguridad:
Cuando utilice comandos de datos con una propiedad CommandType cuyo valor esté establecido en Text, compruebe minuciosamente la información enviada desde el cliente antes de pasarla a la base de datos. Usuarios con malas intenciones podrían intentar enviar (inyectar) instrucciones de SQL modificadas o adicionales con el fin de obtener acceso no autorizado o dañar la base de datos. Antes de transferir los datos proporcionados por el usuario a una base de datos, siempre debe comprobar que la información sea válida. Un procedimiento recomendado es siempre utilizar consultas parametrizadas o procedimientos almacenados cuando sea posible.

Cuando utilice comandos de datos con una propiedad CommandType cuyo valor esté establecido en Text, compruebe minuciosamente la información enviada desde el cliente antes de pasarla a la base de datos. Usuarios con malas intenciones podrían intentar enviar (inyectar) instrucciones de SQL modificadas o adicionales con el fin de obtener acceso no autorizado o dañar la base de datos. Antes de transferir los datos proporcionados por el usuario a una base de datos, siempre debe comprobar que la información sea válida. Un procedimiento recomendado es siempre utilizar consultas parametrizadas o procedimientos almacenados cuando sea posible.

Realizar operaciones de bases de datos directamente tiene sus ventajas determinadas, entre las que se incluyen las siguientes:

**Funcionalidad adicional **Como se ha indicado, existen algunas operaciones, como la ejecución de comandos DDL, que sólo se pueden realizar con comandos de datos.
**Más control sobre la ejecución **Utilizando comandos (y un lector de datos, si se está leyendo información), se puede tener un control más directo sobre cómo y cuándo se ejecuta una instrucción SQL o un procedimiento almacenado y qué sucede con los resultados o los valores devueltos.
Menos operaciones de procesamiento Al leer y escribir directamente en la base de datos, se puede obviar el almacenamiento de la información en un conjunto de datos. Debido a que conjunto de datos necesita memoria, puede reducir alguna sobrecarga en la aplicación. Esto es especialmente cierto en situaciones donde se pretende utilizar los datos sólo una vez, como al mostrar el resultado de una búsqueda en una página Web. En ese caso, crear y rellenar un conjunto de datos podría ser un paso innecesario para mostrar los datos.
**Menor programación en algunas instancias **En unas pocas instancias, concretamente con aplicaciones Web, se requiere alguna programación adicional para guardar el estado de un conjunto de datos. Por ejemplo, en las páginas de formularios Web Forms, la página se vuelve a crear con cada acción de ida y vuelta; a menos que agregue programación para guardar y restaurar un conjunto de datos, esto también se descarta y se vuelve a crear con cada acción de ida y vuelta. Si utiliza un lector de datos para leer información directamente de la base de datos, evitará los pasos adicionales requeridos para administrar el conjunto de datos.

Recomendaciones para obtener acceso a datos

Las secciones siguientes incluyen recomendaciones para elegir la estrategia de acceso a datos dependiendo del tipo de aplicación específico que use.

Formularios Windows Forms

En general, en un formulario Windows Forms, use un conjunto de datos. Los formularios Windows Forms se usan normalmente en aplicaciones de cliente complejas en las que el formulario no se crea y desecha (junto con sus datos) con cada operación del usuario, como en el caso de los formularios Web Forms. Además, las aplicaciones de Windows Forms ofrecen normalmente escenarios de acceso a datos que se benefician del mantenimiento de una caché de registros, como cuando se muestran los registros uno a uno en el formulario. Para obtener más información, vea Crear aplicaciones de datos cliente.

Específicamente, use conjuntos de datos en las siguientes circunstancias:

Si trabaja con los mismos registros una y otra vez, como en el caso de que permita a un usuario navegar entre registros.
Cuando use la arquitectura de enlace de datos de los formularios Windows Forms, que está diseñada especialmente para trabajar con conjuntos de datos.
Por cualquiera otra de las razones mencionadas anteriormente para los formularios Web Forms.

Utilice una consulta de TableAdapter o un comando de datos en las siguientes circunstancias:

Si se va a obtener un valor escalar de la base de datos.
Cuando se esté ejecutando una operación que no sea una consulta, como un comando DDL.
Si se están obteniendo datos de sólo lectura para mostrarlos en un formulario, por ejemplo, al crear un informe. De otro modo, si no hay necesidad de mantener los datos disponibles después de haber tenido acceso a ellos, use un comando de datos.

Formularios Web Forms

En general, use comandos de datos; para recuperar datos, use un lector de datos. Dado que las páginas de los formularios Web Forms y sus controles y componentes se vuelven a crear en cada acción de ida y vuelta al servidor, a menudo no resulta eficaz crear y rellenar un conjunto de datos cada vez, a no ser que se pretenda también almacenarlo en la caché entre idas y vueltas.

Use conjuntos de datos en las siguientes circunstancias:

Si desea trabajar con varias tablas independientes de distintos orígenes de datos.
Cuando esté intercambiando datos con otra aplicación o un componente como un servicio Web XML.
Si tiene que realizar un amplio procesamiento con cada registro que obtenga de la base de datos. Si usa un comando de datos y un lector de datos, procesar cada registro mientras lo lee puede resultar en que la conexión se mantenga abierta por un largo período de tiempo, lo que puede afectar al rendimiento y la escalabilidad de la aplicación.
Si el procesamiento de los datos implica registros de interdependencia, por ejemplo, buscar información en registros relacionados.
Cuando desee realizar operaciones XML como transformaciones XSLT en los datos.
Si prefiere la sencillez de programación que proporcionan los conjuntos de datos.

Servicios Web XML

Los servicios Web XML son aplicaciones Web ASP.NET y, por lo tanto, utilizan el mismo modelo que las páginas de formularios Web Forms: el servicio Web XML se crea y desecha cada vez que se le invoca. Esto sugiere que el modelo de acceso a datos para un servicio Web XML sea el mismo que para los formularios Web Forms. Sin embargo, los servicios Web XML son a menudo objetos de nivel medio, y una parte importante de sus funciones consiste, con frecuencia, en intercambiar datos con otras aplicaciones a través del Web.

Use un conjunto de datos si:

El servicio Web XML envía y recibe datos; por ejemplo, envía datos como el valor devuelto de un método y los recibe como un argumento de un método. Ésta es una elección fundamental en los servicios Web XML; incluso aunque haya otras razones que sugieran que se deba usar un comando de datos, el intercambio de datos con otros componentes casi siempre significa que se debe emplear un conjunto de datos.
Por cualquiera de las razones mencionadas anteriormente para los formularios Web Forms.

Use un comando de datos (y, si resulta apropiado, un lector de datos) en las siguientes circunstancias:

El servicio Web XML va a recuperar un valor escalar.
El servicio Web XML está ejecutando una operación que no es una consulta, como un comando DDL.
El servicio Web XML llama a un procedimiento almacenado para ejecutar lógica en la base de datos.