Cita:
Iniciado por ziel83 
toda la vida programe con vb6
Bienvenido al siglo 21.
Cita:
Iniciado por ziel83 Con vb6 usaba recorset para gestionar los datos, usaba una función que siempre me devolvía un recordset como resultado enviándole la consulta sql como paramtro string. De esta forma no tenia que escribir tanto código.
Si. El paradigma de acceso a datos de VB6 es bastante simple, ya que fue concebido en los '90 (o antes) y contempla los requerimientos que existían en ese momento.
Ya que es un paradigma que consiste en acceso directo desde la UI a la base, no contempla cuestiones como SOA, transacciones, N-Tier, escalabilidad, independencia del RDBMS, cross-platform, separación de responsabilidades, etc, etc, etc, todas cuestiones que sí se tienen en cuenta al construir sistemas modernos.
Cita:
Iniciado por ziel83 Con vb net intento hacer lo mismo
Encarar .Net con una mentalidad de VB6 es un error, .Net es una plataforma moderna que posee características que contemplan todo lo que te menciono arriba, y se adapta a las necesidades de las aplicaciones de hoy en día.
Por ejemplo, hoy por hoy, para desarrollar un sistema, no vas a usar una base de datos de Access y tirar una consulta directamente desde la UI, principalmente porque es muy probable que el usuario quiera acceder a esta informacion a traves de internet, o que tengas que plantear el sistema de forma tal que la informacion y la logica de negocio puedan ser compartidas entre una aplicacion Web, una aplicacion de Windows, y una aplicación de Android. Esto implica que vas a tener que utilizar una arquitectura SOA o alguna otra arquitectura que contemple una separación adecuada de los componentes del sistema para poder reutilizarlos en distintas plataformas, exponer servicios que permitan obtener los datos a traves de internet, etc, etc, etc.
En fin, el mundo de hoy es muy diferente a lo que era en la epoca de Windows 95 (es decir, hace 20 años) cuando la gente usaba VB6 para hacer aplicaciones.
Cita:
Iniciado por ziel83 mi duda es que para llenar un simple combobox siempre tengo que usar un dataset, pero para cargar un datagridview necesito un datatable.
Ambas afirmaciones son incorrectas.
En primer lugar, la UI funciona independientemente del origen de los datos que quieras mostrar en pantalla. Esto significa que al ComboBox (o cualquier otro elemento visual) no le "importa" si los datos vienen de una base de SQL, de un archivo, de un Web Service, o estan hardcodeados en el codigo de tu aplicación.
Todo lo que un ComboBox (en este caso) necesita para mostrar una lista desplegable es una instancia de cualquier clase que implemente la interfaz System.Collections.IEnumerable, es decir, cualquier objeto de .Net que contenga una "lista" o "collección" de otros objetos.
[[Dicho sea de paso, como verás el paradigma de orientación a objetos (OOP) está muy presente en .Net y es muy recomendable que te interiorices al respecto antes de encarar un desarrollo en .Net, ya que en VB6 no se acostumbra utilizar este paradigma, y es un cambio mental que tenés que atravesar.]]
Lo mismo pasa con el DataGrid (o el DataGridView de winforms), al mismo no le interesa de donde vengan los datos y que estructura tengan, simplemente expone una facilidad de mostrar un System.Data.DataTable de manera automatica para casos simples, y por cuestiones de compatibilidad con versiones anteriores.
Con respecto específicamente a la clase System.Data.DataTable, esta clase también existe por cuestiones de compatibilidad, pero prácticamente no se usa hoy por hoy ya que fue reemplazada por mecanismos muchísimo mejores de acceso y modelado de datos en .Net.
Esta forma de modelar los datos usando DataTable tiene muchos problemas, por ejemplo:
- Los "registros" y sus propiedades no existen en forma de un modelo de datos fuertemente tipado, si no que son mas bien "diccionarios" que exponen los datos usando una clave de tipo string, por ejemplo datarow["Apellido"], esto es problemático porque al usar un string de esa manera se pierde la seguridad que brinda el compilador, es decir, si yo tecleo mal, y pongo "Apelldio", voy a tener un error en mi sistema al ejecutarlo, y este error no puede ser atrapado por el compilador de manera anticipada.
- las propiedades que se obtienen de un System.Data.DataRow siempre son devueltas como Object, en lugar de usar el tipo datos que corresponde al dato que se esta manejando. Por ejemplo, si existe una columna de tipo DateTime, con una fecha, y yo quiero tomar ese dato y agregar un dia, como el objeto es devuelvo como Object me veo obligado a "castear" manualmente todo el tiempo para poder manipular la información. Esto es problemático porque ensucia el código y porque básicamente se pierden todas las ventajas de un sistema de tipos estáticos al hacer esto. Es decir yo me podría olvidar que cierto dato es de tipo DateTime, y "castearlo" a String (por ejemplo) y daría un error en tiempo de ejecución. Otra vez, estos errores no pueden ser atrapados por el compilador de manera anticipada, y esto hace que mi sistema pueda fallar severamente "en la cara" del usuario.
En definitiva, hoy por hoy no se usa DataTable, ni DataSet, ni ninguna otra API que pierda el "strong typing", si no que Microsoft recomienda utilizar Entity Framework (
https://msdn.microsoft.com/es-es/data/aa937723) como la plataforma preferida y la primera opción de acceso a datos para aplicaciones en .Net.
Entity Framework provee un conjunto de herramientas que permiten modelar los datos y luego crear la base de datos a partir de estos, o al reves, crear un modelo de datos fuertemente tipado (es decir, un conjunto de clases que representen las tablas de la base y sus relaciones) a partir de una DB existente.
Además de esto, EF utiliza una tecnología de .Net llamada LINQ (
https://msdn.microsoft.com/es-es/library/bb397926.aspx) para ejecutar las consultas contra la base de datos, negando la necesidad de escribir SQL manualmente, ya que EF se encarga de traducir las consultas de LINQ a SQL y ejecutarlas contra la base, devolviendo los resultados como una collección de datos fuertemente tipados, en lugar de utilizar strings y diccionarios horribles y poco practicos.
Cita:
Iniciado por ziel83 Mi opción es crear 2 funciones, que una devuelva un dataset y otra un datatable y usar la que necesite.
Te recomiendo que en lugar de seguir utilizando prácticas de hace 20 años, te actualices y leas acerca del patrón de repositorio, y empieces a pensar en tus datos como un conjunto de clases, en lugar de un monton de diccionarios con claves magicas.
Cita: En definitiva, como hacen ustedes?
Yo tengo desarrollado un Framework propio que utiliza tecnologías de .Net tales como EF, WCF, WPF, XAML, MEF, PCL, LINQ, T4, e implementa patrones de diseño y arquitecturas tales como MVVM, SOA, DI, Repository Pattern, Two-way DataBinding, y hace muchisimo uso de caracteristicas avanzadas de .Net como generics, async, y System.Linq.Expressions.
Este framework me permite hacer aplicaciones enteras, N-Tier, multi capa, basadas en servicios SOA, que pueden ser reutilizados para aplicaciones de Windows, Android, Web, etc, y me permite mantener una estructura robusta y bien definida, y crear aplicaciones con bases de datos SQL sin escribir una sola línea de SQL, y exponer Web Services SOAP sin escribir ni una sola linea de XML.
Por cierto, ya partís de una mala base, desde el momento en que estás usando winforms.
winforms es un framework bastante viejo que también ha quedado en desuso y fue reemplazado por tecnologías basadas en XAML como WPF y WinRT. Estas tecnologías de UI tienen muchísimas ventajas y utilizan paradigmas totalmente diferentes a lo que se usaba en winforms (hace 10 años). Te sugiero que investigues al respecto, ya que seguir usando winforms es muy poco práctico, require más código, produce resultados inferiores, y no es reutilizable (XAML permite reutilizar mucho de la lógica de UI en plataformas tales como Windows Desktop (WPF), Universal Apps (WinRT) e incluso Android e iOS a través de Xamarin.Forms). Además de esto winforms está en modo "soporte" por parte de Microsoft. Es decir, si bien funciona en versiones actuales de Windows, no se le da ningun tipo de avance, no se le agrega funcionalidad nueva (tal como ocurre con VB6), al contrario de lo que pasa con las tecnologías XAML donde MS esta haciendo avances importantísimos (VS2015 trae un conjunto de nuevas herramientas para XAML muy pero muy buenas).
En fin, todo lo que te comento es, a grandes razgos, la forma en la que se programa (profesionalmente) aplicaciones de escritorio o client/server en .Net, hoy, en 2015. Parece mucha información, y lo es, el problema es que estamos en 2015 y (en mi opinión) no tiene mucho sentido haber perdido tanto tiempo "toda la vida" programando en una plataforma arcaica y totalmente obsoleta como VB6 que se dejó de usar hace 15 años.
Una cosa más: Si bien VB.Net es un buen punto de entrada para pasar de VB6 a .Net, no es más que eso. Los lenguajes que se usan para programar profesionalmente en .Net son C# y F#. En general se ve a VB.Net como un lenguaje "para novatos". C# es principalmente OOP y te va a resultar fácil una vez que entiendas como funciona .Net (una vez que sepas usar bien VB.Net, solo es un cambio en la sintaxis, reemplazar END IF por }, etc). F# es un lenguaje principalmente funcional y plantea un paradigma totalmente diferente. Dejalo para más adelante.
Si te interesa programar profesionalmente en .Net, te recomiendo que busques información y leas bastante acerca de todo esto. Hay muchisimo material en linea para ponerte al día y entender el cambio de paradigma mental que implica esto.
De lo contrario, si estas encarando esto como un "hobby" o de forma "casera", podes seguir usando metodos antiguos, pero incluso si así fuera, te conviene estar al tanto de cómo es el mundo de la programación moderna.
Saludos
