¿Por qué todavía usamos DataSets en.NET?

dapper

Question

Los DataSets fueron una de las cosas más importantes en .NET 1.0 e incluso ahora cuando utilizo .NET 3.5. Sigo teniendo que usarlos ... especialmente cuando tengo que llamar a un proc almacenado que devuelve un conjunto de datos que luego termino teniendo. para transformar manualmente en un objeto para que sea más fácil trabajar con él.

Realmente nunca me han gustado los DataSets y los he encontrado molestos de usar ... y como resultado he tendido a mantener mis conocimientos sobre ellos al mínimo (¡probablemente algo muy malo!). También prefiero transformarlos rápidamente en un objeto o una lista de objetos para poder manipularlos fácilmente en mi código.

¿Han pasado DataSets su uso por fecha? Con el advenimiento de los mapeadores de O / R como NHibernate, me pregunto si los DataSets se extinguirán o si todavía hay un lugar para ellos. Por el momento, estoy dividido entre si debería reservar un tiempo para volver a visitar los DataSets y aprender a usarlos correctamente o para ponerme detrás de los mapeadores O / R al 100% y simplemente deshacerme de los DataSets.

¿Los DataSets ofrecen algo que tecnologías como NHibernate y LINQ no pueden ofrecer? Si no, ¿por qué entonces todavía los usamos?

Answer 1

Creo que el mayor problema con los conjuntos de datos es que básicamente te animaron a crear un dbms en la memoria. Me encanta la forma en que Linq / entidades cubren sus necesidades de datos y confían en las clases de colecciones .Net estándar y genéricos para trabajar.

Dicho esto, no descartaría el poder de leer dinámicamente datos sin tipo y aplicar relaciones, etc. en la memoria, que sigue siendo una funcionalidad muy poderosa según su situación.

Answer 2

El uso más publicitado de DataSets es crear una copia en la memoria de la base de datos. Descubrí que nunca lo usé para esto, incluso con .NET 1.0. El modelo desconectado siempre fue inapropiado en un entorno multiusuario.

Si ignora por completo las bases de datos relacionales, todavía hay usos para los DataSets:

• Si está escribiendo una aplicación de formularios que debe cargar y guardar datos en un archivo, puede definir un conjunto de datos tipeado, luego cargarlo y guardarlo usando la clase XmlDataDocument.

• Crystal Reports puede generar informes leyendo DataSets en memoria. Puede crear un DataSet tipeado solo para un informe en particular, y usar el lenguaje .NET para escribir lógica empresarial complicada para completar este DataSet. Esto le ahorra la implementación de la lógica empresarial utilizando la funcionalidad Crystal Reports (que puede ser una tarea realmente difícil)

• Puede adjuntar un DataGridView a un DataSet con una línea de código para obtener una interfaz de usuario horrible, que sin embargo puede hacer el trabajo que necesita. Bueno para cosas como herramientas de prueba internas. (No lo suficientemente bueno para enviar a un cliente).

Answer 3

Nunca utilicé un DataSet correctamente (conectado a un servidor SQL), pero fue útil para una necesidad en particular una vez. Descubrí que DataSet y DataView son clases básicas bastante prácticas y útiles para implementar un nivel de datos / BLL hasta que pude poner en práctica algo realmente pensado. Hay una gran cantidad de funcionalidades que debes tener en cuenta, si nada más.

Answer 4

Creo que estoy en el mismo barco: muy rara vez uso datasets, y ciertamente no pretendo ser un experto en el modelo de adaptador (creo que " Fill " es el único método que realmente he usado en producción) - pero ocasionalmente tienen algunos usos. Por ejemplo, si necesita ejecutar algún código SQL ad-hoc, no puede predecir el esquema (y, por lo tanto, ORM no ayuda), y no quiere meterse con IDataReader etc., para obtener un conjunto de datos simple y pequeño.

Aparte de eso (es decir, la mayoría de las veces), prefiero las clases estándar, ya sea ORM o manual.

Answer 5

Me parece muy bueno para estas tablas (no tanto) que seguro no van a cambiar en mucho tiempo como las listas de elementos o algún tipo de datos históricos.

Answer 6

Para bien o para mal, la respuesta es simplicidad. Cuando salió el Framework 2.0 y TableAdapters se incluyeron en el proceso, se hizo ridículamente fácil obtener su aplicación básica CRUD tipo, o incluso una página principal que muestra datos, rodando. Simplemente conéctese a su servidor, arrastre su (s) tabla (s), y la estructura estaba en su lugar, incluyendo referencias clave externas / principales / únicas. ¿Necesita realizar actualizaciones sobre estos datos? Utilice el asistente, especifique sus procedimientos existentes o permita que el asistente genere los procedimientos adhoc / almacenados para usted.

Y listo, conéctelo a un GridView y podrá hacer muchas cosas rápidamente: recurrir, volver a consultar, editar múltiples registros mientras está desconectado y actualizar en solo o en bloque. Este tipo de conveniencia es difícil de dejar de lado cuando trabajas en proyectos que desean terminar rápido. Además, tener las cosas en este formato nativo de "DataTable" resulta conveniente para shenanigans XML si eso es lo que necesita ya que el modelo DataSet usa XML bajo el capó para muchas cosas.

Debo admitir que no he comprobado las últimas versiones de los ORM, y no estoy seguro de si hay un asistente para LINQ que haga esto con unos pocos clics. Y la mayoría de las personas son un poco lentas para adaptar la tecnología más nueva tal como está, por lo que es fácil ver cómo todavía se usa mucho.

Al ver que el nuevo sitio / proyecto de Dynamic Data Service se construye de LINQ to SQL o LINQ to EF, creo que la marea finalmente podría cambiar al modelo más nuevo.

Answer 7

3 razones para dar me gusta a los conjuntos de datos:

• Para winforms soportan enlace de datos / filtrado la mayoría de los orms no
• Muchas herramientas de terceros (especialmente herramientas de informes) han incorporado soporte para datatables / sets y no para objetos simples.
• Mientras realiza la depuración, puede hacer clic con el botón derecho en una tabla completa y ver los contenidos. Este es un ahorro de tiempo real.
  

En general, tienen mucha funcionalidad. No obstante, no me gustan los adaptadores. Normalmente escribo mis propios adaptadores de bases de datos.

Answer 8

Yo uso Typed DataSets para un orm realmente bajo. Sé que no es la mitad de bueno, pero intenta explicar eso a los peces gordos.
Entonces, en lugar de cambiar el mundo e introducir alguna herramienta oss que no sea de Microsoft (o finalmente migrar de .net2.0 a 3.5, y usar l2s o ef), solo uso un conjunto de datos para mantener los resultados de mi consulta y vincularlos fácilmente a las grillas , cuadros de texto y cuadros combinados donde sea necesario. Encuentro la capacidad de usar más tarde algo así como

MyDataSet.MyDataTableRow row = // whatever
if (row.Price > 100) // do something

muy útil.

Answer 9

Para programadores profesionales. Utilizan DataSet porque el objeto DataSet está diseñado para fomentar el uso de la concurrencia optimista para actividades de larga ejecución, como la comunicación remota de datos y la interacción con datos.