Cuáles son las desventajas de Typed DataSets

Question

Vengo de un mundo que favorece la creación de uno propio en lugar de confiar en las bibliotecas y marcos creados por otros. Después de escapar de este mundo, he encontrado la alegría y la facilidad de usar herramientas como Typed DataSets en Visual Studio. Entonces, además de la pérdida de flexibilidad, ¿qué más pierdes? ¿Hay factores de rendimiento (sin tener en cuenta los procs frente al debate dinámico de sql)? Limitaciones?

Answer 1

El rendimiento se mejora con conjuntos de datos tipeados sobre conjuntos de datos sin tipo (aunque nunca he encontrado problemas de rendimiento con cosas triviales como esa de las que vale la pena preocuparse).

Diría que el mayor problema es mantenerlos sincronizados con su base de datos. No puedo hablar de VS 2008, pero las versiones anteriores no brindan un buen soporte para esto. Literalmente arrastro los procesos hacia el diseñador cada vez que cambia el esquema del conjunto de resultados. No es divertido.

Pero, obtiene la comprobación del tipo de tiempo de compilación que es genial y cosas como Customer.Name en lugar de Dataset.Tables (0) .Rows (0) ("Name").

Por lo tanto, si su esquema es relativamente estático, pueden valer la pena, pero de lo contrario, no me molestaría.

También podría buscar en un ORM real.

Answer 2

No hay nada de malo con los conjuntos de datos tipados. No son perfectos, sin embargo, es un próximo paso hacia la solución del problema de desajuste de la impedancia relacional del objeto. El único problema al que me enfrenté es un soporte débil para los cambios de esquema. Las clases parciales pueden ayudar, pero no en todos los casos.

Answer 3

Solo di Typed Datasets un intento muy corto. Me detuve cuando descubrí que mi código se estaba rompiendo a aproximadamente 2/3 del camino en un archivo de líneas de más de 1000 de código generado.

La otra cosa que no me gustó fue que pensé en escribir código como Customer.Name, pero de forma predeterminada parecía obtener un código como CustomerDataSet.Customers [0] .Name, donde los clientes [0] era del tipo CustomersRow. Aún más agradable de leer que los conjuntos de datos sin tipo, pero no realmente la semántica que estaba buscando.

Personalmente me dirigí hacia abajo por la ruta de ActiveRecord/NHibernate, y no he vuelto a mirar desde entonces.

Answer 4

La principal crítica que extendería es que no se escala bien: el rendimiento sufre debido a la sobrecarga, cuando se llega a un mayor número de transacciones, en comparación con las entidades comerciales livianas o DTO o LINQ a SQL. También existe el dolor de cabeza de los cambios de esquema. Para una arquitectura de "fortaleza industrial", probablemente no sean el camino a seguir, ya que causarán problemas a largo plazo.

Definitivamente todavía los usaría para PoC rápidas y sucias o utilidades simples: son realmente convenientes para trabajar con las herramientas dadas en Visual Studio, y hacer el trabajo.

Answer 5

Los conjuntos de datos tipados son, con mucho, una actualización del mundo de los conjuntos de registros desconectados clásicos de ADO. Descubrí que todavía son agradables de usar en situaciones simples en las que necesita realizar una tarea de ordenación orientada a filas, es decir, desea trabajar en el contexto de un paradigma de base de datos de filas, columnas, restricciones y demás. Si se usa sabiamente en ese contexto, entonces estás bien.

Hay algunas áreas en las que sus beneficios disminuyen:

• creo que los problemas de sincronización trajeron aquí ya están definitivamente un problema, especialmente si usted ha ido y les personalizadas o los utilizaron como una clase base .
• Dependiendo del número de tablas de datos en el conjunto de datos, pueden convertirse en bastante grasa. Me refiero a esto en el sentido de que los conjuntos de datos de varias tablas suelen presentar una vista relacional de los datos. Lo que viene con eso, además de la huella en la memoria, son la definición de claves y potencialmente otras limitaciones. Nuevamente, si eso es lo que necesita, pero si necesita recorrer datos rápidamente, una vez, un bucle eficiente con un lector de datos podría ser un mejor candidato.
• Debido a su compleja definición y tamaño potencial, su uso en situaciones remotas tampoco es aconsejable.
• Finalmente, cuando empiece a darse cuenta de que necesita trabajar con sus datos en objetos que son relevantes para su dominio problemático, su uso se vuelve más un obstáculo que un beneficio. Constantemente está moviendo campos dentro y fuera de las tablas de filas en el conjunto y en relación con el estado de las tablas y filas. Comienzas a darte cuenta de que crearon lenguajes OO para que sea más fácil representar objetos del dominio del problema del mundo real y que trabajar con tablas, filas y columnas no se ajusta realmente a esa forma de pensar.

En general, en mi experiencia, estoy descubriendo que los sistemas complejos (por ejemplo, muchos grandes sistemas empresariales) se alejan del uso de conjuntos de datos y más hacia un modelo de objeto específico de dominio sólido: cómo obtiene sus datos dentro y fuera de esos objetos (usando ORM por ejemplo) es otro tema de conversación. Sin embargo, en proyectos pequeños donde hay una forma abrumada frente a datos que necesitan mantenimiento básico y algunas otras operaciones simples, se puede lograr una gran productividad con el paradigma del conjunto de datos, especialmente cuando se combina con las poderosas funciones de enlace de datos de Visual Studio/.Net.

Answer 6

Los conjuntos de datos son agradables para unir rápidamente algo junto con Visual Studio, si se ignoran todos los problemas mencionados anteriormente. Un problema que no vi mencionar es la escalabilidad visual de los conjuntos de datos dentro de la superficie de diseño de Visual Studio. A medida que el sistema crece, el tamaño de los conjuntos de datos inevitablemente se vuelve difícil de manejar. Los aspectos visuales del diseñador simplemente no se escalan. Es un verdadero dolor desplazarse por ahí tratando de encontrar una tabla o relación particular cuando el conjunto de datos tiene más de 20 o más tablas.

Answer 7

No soy un gran admirador del conjunto de datos tipeados. No hay forma de que pueda mejorar el rendimiento utilizando un conjunto de datos tipeados. Es puramente un envoltorio sobre los objetos de base de datos existentes. No puedo considerar el acceso como employee.empName. La conversión aún se realiza en el contenedor. Otro sobrecarga es gran parte del código. LOC está aumentado. Tantos objetos activos en la memoria. Sin actualización automática de esquema De cualquier manera, el conjunto de datos tipeados no es útil para los desarrolladores, excepto la comodidad que brinda. Como desarrolladores no tenemos ningún derecho a exigir comodidad :) Tome el dolor ... quítele el dolor al usuario :)