manipular - C#: ¿Qué más usa además de DataSet?
recorrer filas y columnas de datatable c# (13)
Acabo de construir mis objetos comerciales desde cero, y casi nunca uso DataTable y, especialmente, ya 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.
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 excursiones sencillas a través de un seleccionado, pero siento que puede haber algunos otros modelos al acecho en .Net que son útiles para aprender más. 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 has tenido con ellas. ¡Gracias!
-Eric Sipple
Desde que salió .NET 3.5, he usado exclusivamente LINQ. Es realmente tan bueno; No veo ninguna razón para usar cualquiera de esas muletas viejas más.
Sin embargo, por muy bueno que sea LINQ, creo que cualquier sistema ORM te permitirá eliminar ese desastre.
Estaba harto de DataSets en .Net 1.1, al menos lo optimizaron para que no se ralentizara tan exponencialmente para los grandes conjuntos.
Siempre fue un modelo bastante inflado: 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 IEnumerable<T> de mi fila de datos.
Linq es un reemplazo mucho mejor en mi opinión.
Los DataSets son geniales para demostraciones.
No sabría qué hacer con uno si me hicieras usarlo.
Yo uso ObservableCollection
Entonces nuevamente estoy en el espacio de la aplicación del 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 transmisión solo hacia adelante del conjunto de resultados.
Los uso extensamente pero no uso 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.
Nos alejamos de los conjuntos de datos y construimos nuestros propios objetos ORM basados en 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''.
Pre linq Utilicé DataReader para completar la Lista de mis propios objetos de dominio personalizados, pero post linq he estado usando L2S para completar entidades de L2S, o L2S para completar objetos de dominio.
Una vez que tenga un poco más de tiempo para investigar, sospecho que los objetos de Entity Framework serán mi nueva solución favorita.
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 y filas sin procesar 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 asignar columnas a los campos o rellenar todo el tiempo. Objetos de comando Sql y todos los otros saltos de aro que todos pasamos una vez.
Me encanta 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. :PAG
He estado usando el patrón Objetos de transferencia de datos (originalmente del mundo Java, creo), con un SqDataReader para llenar las 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.
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.
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, aquí hay una versión del comando que uso para trabajar con él (para que no tengas que pelear muy 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 archivo 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 ahora tiene más de un año. 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.
He utilizado DataSets mecanografiados 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.
Los DataSets mecanografiados 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.
EDITAR:
Algunos sugieren que los 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. Los DataSets mecanografiados pueden tener una huella de memoria más grande que otras opciones, pero todavía tengo que ver la aplicación donde esto hace una diferencia tangible.
Use 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.
He utilizado DataSets mecanografiados y sin tipo, DataViewManagers, DataViews, DataTables, DataRows, DataRowViews, y prácticamente todo lo que se 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.
Utilizo el enlace ADO.NET en Winforms y también uso el código en las aplicaciones de la 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.