Escogiendo entre DataSets y DataReaders
El escojer una metodología de acceso a datos adecuada para las necesiades de la aplicación en construcción es uno de los temas que más polémica y dudas causa a los desarrolladores de la plataforma .NET. En este pequeño artículo resumo algunas de mis razones y conclusiones que sigo fielmente a la hora de escojer mi propia metodología.
La regla fundamental es esta:
Usar siempre DataSets, a menos que se tenga una buena razón para utilizar DataReaders.
Explico esta afirmación desde los dos puntos de vista más importantes a considerar: Rendimiento y Productividad.
Rendimiento
Los DataReaders son usualmente más rápidos, dado que no poseen el costo asociado con la creación de los DataSets. Sin embargo, los DataReaders son menos flexibles y son poco útiles en situaciones en las que se necesita hacer caché de datos en memoria y pasar los datos hacia componentes en una aplicación que tiene varias capas.
Se prefiere el uso de DataReaders cuando se cumplen las siguientes condiciones:
- Se necesita acceso solo hacia adelante y de solo lectura a los datos y se requiere acceder a los datos tan rápido como sea posible y no se necesita hacer caché de los mismos.
- Se posee un contenedor, como por ejemplo un componente de negocios en el cual se puede colocar los datos.
Se prefiere el uso de DataSets cuando las siguientes condiciones sean ciertas:
- Se necesita hacer caché de datos o pasar los datos entre capas.
- Se necesita tener una vista relacional de los datos en memoria.
- Se desea actualizar algunas o todas las filas retornadas y/o se desea hacer actualizaciones en batch a través del DataAdapter.
- Se necesita enlazar datos a un tipo de control al que los DataReaders no pueden ser enlazados. La mayoría de los controles de Windows Forms necesitan un origen de datos que implemente la interfaz IList. El DataSet implementa IList, pero el DataReader implementa IEnumerable. Por ello, los DataReaders se pueden enlazar a la mayoría de los controles Web, pero no a la mayoría de los controles Windows.
- Se necesita accesar a múltiples sets de datos al mismo tiempo, y no se quiere mantener abiertas las conexiones al servidor.
- Los DataSets en ADO.NET 2.0 han sido mejorados (prácticamente reescritos) de tal forma que ahora pueden procesar millones de registros en tan solo unos pocos segundos, cosa que en ADO.NET 1.1 usualmente tomaba varios minutos e incluso horas.
- Los DataSets en ADO.NET 2.0 soportan serialización binaria, lo cual les permite viajar entre el cliente y el servidor mucho más rápido que en ADO.NET 1.1, ya que antes solo podían viajar en formato XML.
Productividad
El utilizar DataReaders como medio para acceder a los datos lleva irremediablemente a construir entidades o clases de negocios que alojen los datos traidos por los Readers para así poder llevarlos hacia capas superiores. Esto es el inicio de un largo camino en el que hay que ingeniárselas para resolver cientos de problemas que se presentan al tener que trabajar con entidades personalizadas, cosa que no ocurre nunca con los datasets, pues estos ya incorporan todo lo que se necesita para llevar los datos entre capas.
En la mayoría de los casos, se debería diseñar la aplicación para que se centre en los datos. Se puede utilizar la flexibilidad y la funcionalidad nativa de los DataSets para soportar múltiples clientes (Windows, Web, etc) con gran facilidad, reducir la cantidad de código personalizado y usar una API (Interfaz de Programación de Aplicaciones) que sea familiar a la mayoría de los desarrolladores. Aunque el trabajar con datos de una forma puramente orientada a objetos tiene sus beneficios, el codificar a mano entidades de negocios complejas incrementa drásticamente el tiempo de desarrollo y los costos de mantenimiento en proporción a la cantidad de características que se desea proveer.
Se prefiere el uso de DataReaders cuando se cumplen las siguientes condiciones:
- Se tiene todo el tiempo del mundo para ponerse a escribir entidades de negocio propias y para construir varias abstracciones que le permitan a uno escribir rápidamente el código que llevará los datos desde el Reader hacia tus clases de negocio. Escribir entidades de negocio personalizadas es una tarea que conlleva múltiples complejidades y que requiere un nivel bastante alto de conocimientos de todos los desarrolladores que intervendrán en el desarrollo de la aplicación.
- Se posee los recursos ($$$) sufientes como para comprar un excelente generador de código ó un excelente ORM (Object Relational Mapper) que resuelva todos los problemas de convertir datos en entidades de negocios.
- Los "jefes" o el cliente han impuesto unas métricas de rendimiento tan pero tan altas que uno se ve forzado a utilizar DataReaders por su alta velocidad. Este caso es muy pero muy poco usual, ya que los DataSets tienen un rendimiento sumamente alto hoy en día y rara vez se nota la diferencia entre el comportamiento de ambos.
Se prefiere el uso de DataSets cuando se cumple lo siguiente:
- Se tiene un cronograma que no da tiempo para hacer nada más que resolver el problema del cliente de la mejor forma posible. Por lo tanto, no hay tiempo para reinventar la rueda haciendo entidades de negocio propias. Los datasets tienen un impresionante número de funcionalidades que son increíblemente útiles en el trabajo diario. Cuestiones como búsquedas, filtrados, tranferencia de datos, traida de datos, actualizaciones masivas, manejo de errores, enlace con controles, manejo de valores Null, etc. Los Datasets poseen todo lo que le tomaría meses y hasta años construir y estabilizar a uno solo o a un equipo de desarrollo.
- Se necesita tener una manera tan estándar de trabajar con los datos que el incorporar a nuevos desarrolladores no force a enseñarle a cada uno la manera de utilizar las clases personalizadas que solo el líder de desarrollo conoce como usarlas. Toda persona que aprende ADO.NET conoce cómo hacer las típicas tareas de acceso a datos y manipulación de los mismos utilizando DataSets.
- No se quiere lidear con las complejidades que implica el serializar objetos complejos entre capas de la aplicación, como cuando se utiliza clientes Windows y Servicios Web y se necesita transferir datos entre ellos.
- Se desea reducir dramáticamente la cantidad de código escrito para acceder a datos. Al usar datasets se utiliza interfaces sumamente amigables y listas para usar, más aún si se utiliza DataSets tipificados, los cuales pueden ser diseñados visualmente en el Diseñador de Datasets de Visual Studio. Aquí cabe recalcar que el nuevo diseñador de datasets de Visual Studio 2005 es sumamente poderoso y amigable, mucho más que el de Visual Studio 2003, de manera que, usualmente, no se tendrá que escribir casi ninguna línea de código para hacer las tareas de acceso a datos desde .NET.
Es realmente recomendable utilizar DataSets para el acceso y manipulación de datos, a menos que una de las condiciones descritas arriba lleve a la persona a utilizar Readers. Lo expuesto aquí tampoco significa que se deba usar 100% DataSets o 100% DataReaders. Lo más común es escojer DataSets para resolver el 80% o 90% de los escenarios y utilizar Readers para resolver escenarios muy especiales que realmente demandan un rendimiento muy superior para ser factibles.
Lecturas adicionales recomendadas: