Datasets ¿Sí o no?
Los Datasets forman parte de ADO.NET. Una librería de acceso a datos (no solo bases de datos relacionales) que se usa en el framework. Desde la versión 2.0 del framework tomaron si cabe más protagonismo debido al nuevo enfoque. Los Datasets se completaron con los TableAdapters. Clases concebidas para trabajar en conjunto y que exponen una serie de consultas de casi cualquier tipo que pueden ser diseñadas de manera muy cómoda a través del Visual Studio.
Los puntos fuertes son muchísimos, seguro que muchos fuera de mi conocimiento por falta de uso. Nos limitamos a utilizarlos a través de un Access o SQL Server pero van más allá. Queda ya para la historia su capacidad de integrar mediante un mismo modelo de programación el acceso a tantos tipos de datos distintos, además de permitirnos trabajar en nuestra aplicación directamente y de manera desconectada con nuestro origen de datos y siempre con variables debidamente tipadas. Esencial también y punto estrella para mí, el haber ofrecido de manera transparente y casi desconocida la parametrización de las consultas SQL evitando de esta manera infinidad de errores de Inyección SQL y comodidad extrema a la hora de pasar parámetros a la query (¿acaso alguien recuerda ya pasar una fecha al formato SQL correcto?).
Hago incapié en la seguridad y en la inyección SQL por la peligrosidad de este tipo de fallos de los que tan solo el programador se puede proteger (no hay política de seguridad que tu compañía de hosting te pueda ofrecer). Especialmente peligroso en motores potentes como SQL Server, Oracle, etc. que son capaces de ejecutar varios comandos en una misma sentencia simplemente separando por punto y coma. Un atacante hábil en una consulta mal parametrizada puede manipular la SQL completándola y añadiendo detrás la query más dañina que se le ocurra. No os costará nada encontrar muchísima literatura sobre el tema y algunos casos famosos.
Por desgracia, todas estas ventajas no son gratis o baratas desde el punto de vista de la eficiencia. Los datasets son objetos complejos que no solo representan tablas si no que además representan relaciones entre tablas. Esto que no deja de ser una ventaja en muchos escenarios supone que al realizar operaciones sobre el DataSet es necesario comprobar que las restricciones de integridad referencial se cumplen, con el coste computacional asociado.
He visto en muchos proyectos además, la manía de arrastrar tantas tablas como se pueda. En muchas ocasiones no hace más que provocar una caida de rendimiento en varios aspectos. En primer lugar en tiempo de ejecución. Un DataSet mal dimensionado es más lento al cargarse y además mucho más lento al operar con él. Además, en el trabajo del día a día del programador, manejar uno de estos a través del Visual Studio puede ser una odisea.
Desde un punto de vista transaccional, si no proponemos una estructura mejor cada operación con un TableAdapter inicializa una nueva conexión. Ello nos limita a la hora de utilizar transacciones, ya sea a nivel del motor de base de datos, o a un nivel superior utilizando clases como el TransactionScope del framework. Sobra decir que cada vez cuesta más encontrar aplicaciones donde se pueda pasar sin entender una infinidad de operaciones de manera atómica y más en un entorno tan distribuido como el actual.
Para terminar, desde el punto de vista de la interoperabilidad. Probablemente te interese esta parte si te estás iniciando en WCF o tecnologías similares. El hecho de que un Dataset se serialice automáticamente como XML no quiere decir que todas las aplicaciones sean capaz de interpretarlo. De hecho, será dificil de ver si la aplicación consumidora del servicio no es .NET. El schema del DataSet puede es complicado de procesar y en la mayoría de los casos tremendamente pesado en comparación con serializar una clase formada por tipos básicos o con una serialización personalizada.
