C#: ¿Qué más usa además DataSet

Question

Cada vez estoy más insatisfecho con el paradigma DataSet/DataTable/DataRow en .Net, sobre todo porque a menudo es un par de pasos más complicado de lo que realmente quiero hacer. En los casos en que me estoy vinculando a los controles, los DataSets están bien. Pero en otros casos, parece haber una buena cantidad de gastos generales mentales.

He jugado un poco con SqlDataReader, y eso parece ser bueno para simples recorridos a través de una selección, pero siento que puede haber algunos otros modelos al acecho de .Net que son útiles para aprender más sobre. Siento que toda la ayuda que encuentro en esto solo usa DataSet por defecto. Tal vez eso y DataReader realmente son las mejores opciones.

No estoy buscando el mejor/peor colapso, solo curiosidad por cuáles son mis opciones y qué experiencias ha tenido con ellas. ¡Gracias!

-Eric Sipple

Answer 1

Desde .NET 3.5 salió, he utilizado exclusivamente LINQ. Es realmente tan bueno; No veo ninguna razón para usar cualquiera de esas muletas viejas más.

Sin embargo, aunque LINQ es bueno, creo que cualquier sistema ORM le permitirá deshacerse de ese dreck.

Answer 2

Nos hemos alejado de los conjuntos de datos y hemos creado nuestros propios objetos ORM de forma flexible en base al CSLA. Puede hacer el mismo trabajo con un DataSet o LINQ o ORM, pero volver a usarlo (lo hemos encontrado) es mucho más fácil. 'Menos código hace más feliz'.

Answer 3

Los uso ampliamente pero no utilizo ninguna de las características "avanzadas" que Microsoft realmente estaba presionando cuando salió el framework por primera vez. Básicamente, simplemente los estoy usando como listas de hashtables, que me parecen perfectamente útiles.

No he visto buenos resultados cuando las personas han tratado de crear conjuntos de datos con tipos complejos, o han intentado establecer realmente las relaciones de claves externas entre tablas con DataSets.

Por supuesto, soy uno de los más extraños que realmente prefiere un DataRow a una instancia de objeto de entidad.

Answer 4

Pre linq Utilicé DataReader para completar la Lista de mis propios objetos de dominio personalizados, pero post linq he estado utilizando L2S para completar entidades L2S, o L2S para completar objetos de dominio.

Una vez que tengo un poco más de tiempo para investigar ¡sospecho que los objetos de Entity Framework serán mi nueva solución favorita!

Answer 5

Estaba harto de DataSets en .Net 1.1, al menos lo optimizaron para que no se ralentizara tan exponencialmente para juegos grandes.

Siempre fue un modelo bastante hinchado: no he visto muchas aplicaciones que utilicen la mayoría de sus funciones.

SqlDataReader era bueno, pero solía envolverlo en un IEnumerable<T> donde el T era una representación tipada de mi fila de datos.

Linq es un reemplazo mucho mejor en mi opinión.

Answer 6

Acabo de construir mis objetos comerciales desde cero, y casi nunca uso DataTable y, especialmente, no el DataSet, excepto para poblar inicialmente los objetos comerciales. Las ventajas de construir las suyas son la capacidad de prueba, el tipo de seguridad y intellisense, la extensibilidad (intente agregar a un DataSet) y la legibilidad (a menos que le guste leer cosas como Convert.ToDecimal (dt.Rows [i] ["blah"]. ToString())).

Si fuera más inteligente también usaría un marco de DI de terceros y de ORM, pero aún no lo he sentido. Estoy haciendo muchos proyectos pequeños o adiciones a proyectos más grandes.

Answer 7

Los DataSets son geniales para demostraciones.

No sabría qué hacer con una si me hiciste usarla.

utilizo ObservableCollection

Por otra parte estoy en el espacio de aplicación cliente, WPF y Silverlight. Pasar un conjunto de datos o una tabla de datos a través de un servicio es ... asqueroso.

Los DataReaders son rápidos, ya que son una secuencia directa del conjunto de resultados.

Answer 8

La selección de una herramienta ORM moderna, estable y con soporte activo tiene que ser probablemente el mayor impulso a la productividad que puede obtener cualquier proyecto de tamaño y complejidad moderados. Si está concluyendo que tiene absoluta, absolutamente, que escribir su propio DAL y ORM, probablemente lo está haciendo mal (o está usando la base de datos más oscura del mundo).

Si está haciendo datasets brutos y filas y lo que no, dedique un día para probar un ORM y se sorprenderá de lo mucho más productivo que puede ser sin todo el trabajo pesado de las columnas de mapeo en campos o todo el tiempo llenando objetos de comando Sql y todos los otros saltos de aro que todos pasamos una vez.

Me encantan algunas Subsonic, aunque para proyectos de menor escala junto con demos/prototipos, creo que Linq to Sql es bastante útil también. Odio EF con una pasión sin embargo. : P

Answer 9

He estado usando el patrón Data Transfer Objects (originalmente del mundo de Java, creo), con un SqDataReader para poblar colecciones de DTO de la capa de datos para usar en otras capas de la aplicación. Los DTO en sí mismos son clases muy ligeras y simples compuestas de propiedades con get/sets. Se pueden serializar/deserializar fácilmente, y se pueden usar para enlazar datos, lo que los hace bastante adecuados para la mayoría de mis necesidades de desarrollo.

Answer 10

NUNCA utilizo conjuntos de datos. Son objetos grandes y pesados ​​que solo se pueden usar (como alguien señaló aquí) para "demoware". Aquí se muestran muchas alternativas excelentes.

Answer 11

Soy un gran fan de SubSonic. Un archivo Batch/CMD bien escrito puede generar un modelo de objetos completo para su base de datos en minutos; puede compilarlo en su propia DLL y usarlo según sea necesario. Maravilloso modelo, maravillosa herramienta. El sitio lo hace parecer como un trato de ASP.NET, pero en general funciona maravillosamente en casi cualquier lugar si no está tratando de usar su marco de interfaz de usuario (que me decepciona moderadamente) o sus herramientas de autogeneración a nivel de aplicación .

Para el registro, que aquí es una versión del comando que utilizo para trabajar con él (de modo que usted no tiene que luchar demasiado duro al principio):

sonic.exe generate /server [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true 

Eso lo hace todo el tiempo. Luego construya el DLL fuera de ese directorio, esto es parte de un proyecto NAnt, disparado por CruiseControl.NET, y listo. Estoy usando eso en WinForms, ASP.NET, incluso algunas utilidades de línea de comandos. Esto genera la menor cantidad de dependencias y la mayor "portabilidad" (entre proyectos relacionados, EG).

Nota

Lo anterior es ahora más de un año de edad. Mientras sigo teniendo gran afición en mi corazón por SubSonic, he pasado a LINQ-to-SQL cuando tengo el lujo de trabajar en .NET 3.5. En .NET 2.0, sigo usando SubSonic. Entonces, mi nuevo consejo oficial depende de la plataforma. En el caso de .NET 3+, vaya con la respuesta aceptada. En el caso de .NET 2.0, ve con SubSonic.

Answer 12

Utilicé DataSets escritos para varios proyectos. Modelan bien la base de datos, imponen restricciones en el lado del cliente y, en general, son una tecnología de acceso a datos sólida, especialmente con los cambios en .NET 2.0 con TableAdapters.

Typed DataSets reciben mala reputación de las personas que les gusta usar palabras emotivas como "hinchado" para describirlas. Garantizaré que me gusta usar un buen mapeador O/R más que usar DataSets; simplemente "parece" mejor usar objetos y colecciones en lugar de DataTables, DataRows, etc., pero lo que he encontrado es que si por alguna razón no puedes o no quieres usar un asignador O/R, mecanografiado Los DataSets son una buena opción sólida que son fáciles de usar y le brindarán el 90% de los beneficios de un asignador O/R.

EDIT:

Algunos aquí sugieren que DataReaders son la alternativa "rápida". Pero si usa Reflector para ver las partes internas de un DataAdapter (que DataTables están ocupadas), verá que usa ... un DataReader. Typed DataSets puede tienen una huella de memoria más grande que otras opciones, pero aún no he visto la aplicación donde esto hace una diferencia tangible.

Utilice la mejor herramienta para el trabajo. No tome su decisión sobre la base de palabras emotivas como "grosero" o "hinchado" que no tienen ninguna base fáctica.

Answer 13

Utilicé DataSets con tipo y sin tipo, DataViewManagers, DataViews, DataTables, DataRows, DataRowViews y casi todo lo que puede hacer con la pila desde su primera aparición en múltiples proyectos empresariales. Me tomó un tiempo acostumbrarme a cómo permitir que funcionase. He escrito componentes personalizados que aprovechan la pila ya que ADO.NET no me da exactamente lo que realmente necesitaba. Uno de esos componentes compara DataSets y luego actualiza las tiendas de back-end. Realmente sé cómo funcionan todos estos elementos y aquellos que han visto lo que hice están muy impresionados de que haya logrado ir más allá de lo que creía que solo era útil para el uso de demostraciones.

Uso el enlace ADO.NET en Winforms y también uso el código en aplicaciones de consola. Recientemente me he asociado con otro desarrollador para crear un ORM personalizado que usamos contra un modelo de datos loco que nos dieron contratistas que no se parecían en nada a nuestras tiendas de datos normales.

Busqué hoy para reemplazar a ADO.NET y no veo nada que deba tratar de aprender a reemplazar lo que uso actualmente.