VB.Net mucho mas codificación?

Triastan-

Ah ja ; )

Saludos,
Harvey Triana


"Tristan" escribió en el mensaje
news:

Solo un comentario a:

En cuanto a líneas de código VB.NET / VB, la gran diferencia (no ventaja)
de VB.NET frente al VB es el framework, es decir, una basta gama de
clases donde el programador solo tiene que teclear nombres y puntos, y
poca lógica. En realidad el arte de programar se deja un poco de lado ().

Bueno yo diría que en cierto sentido tienes razón en eso, una de los
objetivo de la OOP es convertir el arte de programar en una ciencia. El
programador pasa de ser un artesano a ser un ensamblador de piezas. Yo lo
veo en cierto sentido como el paso de la producción artesanal a la
producción en serie.

Es cierto que ya era posible con otras versiones de VB trabajar con
componentes preconstruidos (OCX, o en general COM) pero ahora la librería
de componentes, el framework, es inmensamente mayor y las facilidades para
ampliarlo también.

La principal dificultad a la hora de cambiar de vb a vb.net es que para
sacar partido a los cambios es necesario cambiar de paradigma, y ese es el
paso más difícil siempre. Los que han tenido la suerte de empezar desde
cero o los que están dispuestos a modificar sus planteamientos sólo pueden
encontrar ventajas.

Juan Carlos Badiola
MVP - C#

Por ahora nada Tristan estoy algo así como descubriendo la pólvora por mi
mismo, claro que he encontrado buenos recursos en este grupo, aún así he
mandado a pedir la Biblia de .NET, Programing with ADO.NET, VB.NET con base
de datos bueno para darles una hojeada. Poco a poco estoy descubriendo cosas
interesantes. Aunque por citar un caso concreto a ver que opinas del DataGrid
no te parece un poco pesadito.
En fin como tu dices es cuestión de cambiar de paradigma. Suerte por los que
recién empiezan quizá en un futuro aparezca VB.SUPER.NET.XXX.20000 y también
les choque el cambio. Ya estaré fastidiando mas adelante. Ah eso si pido a la
Microsoft optimicen sus requerimientos de hardware. Hagan de .NET un lenguaje
super veloz que no consuma muchos recursos de las pc(s). Si no es mucho pedir
por supuesto...


"Tristan" escribió:

Me gustaría saber raiderf, un caso concreto en el que creas que hay que
escribir más código en vb.net. Es posible que te podamos ayudar a mejorar tu
código si sabemos donde tienes dificultades.

Juan Carlos Badiola
MVP - C#

Imaginaba que lo que te estaba costando trabajo es el datagrid, o más bien
el acceso a datos mediante ado.net.

Ado.net está orientado a trabajar de forma desconectada. Trabajar de forma
desconectada es casi una obligación cuando se pretende crear grandes
aplicaciones con muchos usuarios accediendo a la BD simultaneamente, por
contra complica un poco las cosas cuando se trabaja con pequeñas
aplicaciones con poco acceso a la BD. Utilizar cursores conectados tal y
como permite ado puede ser algo más sencillo pero produce un rendimiento
lamentable cuando la aplicación crece.

Lo que es importante es que uno de los puntos fuertes de .net es que permite
utilizar COM sin ninguna dificultad. Nada te impide seguir utilizando ado y
el datagrid de ado en una aplicación vb.net. No es lo que yo recomendaría,
pero puedes seguir utilizando el mismo código ado de tus aplicaciones vb6 .
No necesitarás escribir ni una sola línea de código más.

De todas formas, una vez que te familiarices con la filosofía de ado.net,
verás que tampoco es tan difícil. La mayor parte del trabajo lo puedes hacer
con el asistente que te genera el dataAdapter. Los DataSet tipados también
pueden resultarte de ayuda.


Juan Carlos Badiola
MVP - C#

Estimado colega
Hoy, después de mucho tiempo de tener unos CD de VB.net (2 añitos), me bajé
el vb.net 2005, agarré un proyecto de los que considero chico, y le puse a
correr el traductor de vb6 a .net en una pentium II con 256MB, hace 6 horas
que lo está haciendo y aún no terminó, estoy empezando a preocuparme, para ir
chusmeando un poco edité los nuevos forms que está generando y son enormes,
más preocupado aún.
Hoy a la noche lo voy a dejar con un proyecto que considero grande, unos 150
forms, vamos a ver qué pasa con una P4 de 3G y 512 de ram.
Con respecto al uso del equipamiento, veo que constantemente se pide más y
más, y me parece que en gran medida se origina porque tendemos a usar
herramientas de desarrollo (mágicas), que en 5 min. hacemos algo parecido a
un desarrollo pero con un costo enorme en recursos de equipo.
Espero que esta nueva herramienta me permita hilar fino a la hora de
programar y así no malgastar recursos, caso contrario la clientela me dirá
"QUE LENTO QUE ANDA ESTO, PONE EL ANTERIOR QUE ANDABA MEJOR !!!"

Un abrazo, Edgardo (BA Arg.)

En general creo que es recomendable no migrar las aplicaciones de vb6 a
vb.net. Si tu aplicación funciona en vb6 sigue con ella. Utiliza vb.net para
los nuevos desarrollos. No he probado todavía el asistente para la migración
de vb6 incluido en vb.net 2005 pero imagino que seguirá siendo igual de poco
útil que el anterior.

Juan Carlos Badiola
MVP - C#