Visual Basic.NET - El porque de las cosas. Necesito un guía. Por favor

 
Vista:
sin imagen de perfil
Val: 17
Ha aumentado su posición en 3 puestos en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por Xavi (7 intervenciones) el 06/03/2019 18:24:59
Hola a todos
Estoy en el duro y largo traspaso de vb6 a .net y mas o menos lo llevo bien

PERO tengo la necesidad de saber porqué los de Microsoft quitaron los index de los controles
en tiempo de diseño, con su evento (Index As Integer). este detalle es el que mas me tira para atrás
a la hora del salto a .net

Y PORQUE los enabled.false casi no se ven. una cosa es que no quiera que se modifique un campo
y otra que no se pueda ni leer. (NO podrian poner una propiedad que elijas el color?)

Por favor si alguien tiene la posibilidad de contactar con los de Microsoft y preguntarles porque lo
han suprimido y porque no lo vuelven a poner, pues creo que miles de programadores de vb6 les
estaríamos eternamente agradecidos.

En caso contrario alguien amablemente podría al menos darme los argumentos de porque
tiene que ser así.?

Muchas gracias de antemano y esperaré ansioso alguna voz que me guíe en este arduo camino.
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder
Imágen de perfil de Phil Rob
Val: 2.160
Oro
Ha mantenido su posición en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por Phil Rob (531 intervenciones) el 06/03/2019 22:44:02
Hola,

Disculpa mi malo español ... estoy aprendiendo ...

Pregunta para qué VB.Net es como es ...
No puebe dale la solución y he abandonado VB6 después año 2005.

Pero, puebe te ayudado sobre preguntas precisas.

Por ejemplo, habla de Index : "... porqué los de Microsoft quitaron los index de los controles ...", este no es importante.
Como tratar los codigos de otra manera es la pregunta importante.
Ahi, los controles de un formulario estan en la colección "Controls" qui tiene un Index :
1
2
3
For Each C As Object In Me.Controls  ' Acceso cada control sin index
' ...
MessageBox.Show(Me.Controls(1).Name)  ' Acceso al control con index = 1, los indices son desde 0 hasta Count - 1

Hasta pronto ...
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar
sin imagen de perfil
Val: 145
Ha mantenido su posición en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por Agustin (24 intervenciones) el 06/03/2019 23:50:11
Yo creo que tenés que olvidarte de todo lo que crees que sabés y empezar desde cero con paradigmas modernos.

Desde el vamos, el hecho de crear un array de controles está mal planteado. Los controles visuales son representaciones del estado o los datos de tu aplicación, por lo tanto en ningún caso deberías usar un array con índice para "acceder" a ningún control visual, sino muy por el contrario crear una estructura de datos que represente la información que querés mostrar y usar técnicas modernas de GUI (como por ejemplo DataBinding y MVVM) para que la GUI se manifieste como lo que es: la representación visual de los datos de tu aplicación.

Te dejo esto como ejemplo: https://github.com/agleiva/calendario

Fijate que estoy mostrando un calendario de un año entero, y existen exactamente CERO líneas de código que manipulan los controles visuales.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar
Imágen de perfil de gilman
Val: 222
Bronce
Ha mantenido su posición en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por gilman (70 intervenciones) el 07/03/2019 09:32:34
El uso de los array de controles en VB6 venía motivado por dos razones:
1.- Poder crear controles en tiempo de ejecución, la manera mas sencilla, aunque no la única, es creando un array de controles en diseño y luego usar la sentencia Load
2.- Poder controlar todos los controles con un único evento, sin necesidad de escribir el código para cada control, cuando los código sería básicamente el mismo para todos los controles incluidos en el Array
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Private Sub Form_Load()
 
    Load lblArray(1)
    With lblArray(1)
        .Move 200, 200
        .Caption = "Etiqueta añadida"
        .Visible = True
 
    End With
End Sub
 
Private Sub lblArray_Click(Index As Integer)
 
    MsgBox "Has clickado la etiqueta " & 1
 
End Sub

Estos dos puntos ya no son necesarios en VBNet
1.- La creación de controles en tiempo de ejecución es sencilla, aún no teniendo un control de referencia.
2.- Un solo procedimiento puede controlar los eventos de múltiples controles y no necesariamente del mismo tipo de control ni evento, siempre que tengan la misma firma

En el ejemplo siguiente se han creado en diseño dos etiquetas llamadas lblEtiqueta1 y lblEtiqueta2.Click, luego en tiempo de ejecución se ha creado una tercera etiqueta y se le dan los valores necesarios a sus propiedades y se enlaza con sus controladores de evento
En este caso en diseño se ha añadido una etiqueta llamada lblArray con indice 0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    Dim Etiqueta As New System.Windows.Forms.Label
    With Etiqueta
        .AutoSize = True
        .Location = New System.Drawing.Point(19, 30)
        .Name = "Etiqueta"
        .Size = New System.Drawing.Size(31, 13)
        .TabIndex = 0
        .Text = "Etiqueta añadida"
        .Visible = True
        Me.Controls.Add(Etiqueta)
        'añadimos los controladores de evento a la 
        AddHandler Etiqueta.Click, AddressOf Etiqueta_Click
    End With
 
 
End Sub
 
'Mediante la clausula Handles se pueden controlar multiples eventos, siempre y cuando tengan la misma firma
'no siendo necesario que el tipo del control, ni el evento sean los mismos
Private Sub Etiqueta_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles lblEtiqueta1.Click, lblEtiqueta2.Click
    MessageBox.Show("Has clickado la etiqueta " & sender.text)
End Sub
Dicho esto la única razón para mantener una estructura similar a los arrays de controles sería por razones de compatibilidad con VB6 y Microsoft no estaba por la labor.
Si necesitas migrar un proyecto VB6 a VBNet y contiene arrays de controles, echa un vistazo al siguiente link

http://www.foro.vb-mundo.com/forum/programacion/visual-basic-net/155763-arrays-de-controles-con-vb-net
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar
sin imagen de perfil
Val: 17
Ha aumentado su posición en 3 puestos en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por xavi (7 intervenciones) el 07/03/2019 10:24:49
Muchas gracias por vuestras respuestas.

Aun que ya os entiendo y de hecho hace tiempo que indago sobre el tema,
no creéis que es mas incomodo y mas laborioso por ejemplo si pongo
20 buttons tener que escribir en el evento button_click
después del handles button1.click, button2.click .... asta 20 para que al pulsar todos vallan al mismo evento?

o escribir el mismo código en los 20 eventos que generaría cada button_click ?

Seguro que Miscrosoft si lo ha hecho de esta manera será por algo, pero no creeis que era mas práctico, comodo y
menos escritura de código con el antiguo y añorado...

Private Sub Command1_Click(Index As Integer) ?

Y saber si Microsoft lo ha hecho asi realmente por que es mejor y necesario o simplemente a suprimido el index sin mas.

Muchísimas gracias a todos de verdad, me ayuda mucho que me saquéis algunas dudas que me comen la cabeza
del porque de algunas cosas.
Un Abrazo
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 145
Ha mantenido su posición en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por Agustin (24 intervenciones) el 07/03/2019 13:27:55
A juzgar por tus comentarios, parece que no te tomaste el tiempo de ver mi ejemplo.

Te recomiendo que lo veas, y si no entendes algo me preguntas, pero viendo ese ejemplo vas a entender lo facil que es hacer cualquier cosa usando paradigmas modernos. Fijate que no tuve que "poner" botones en ningún lado. Simplemente creé una estructura de datos que representa lo que quiero mostrar en pantalla y con eso la pantalla se "pone" a si misma.

De nuevo, te invito a que revises este ejemplo: https://github.com/agleiva/calendario

Está en C#, pero si no lo entendes te lo traduzco a VB.NET fácilmente. Ambos lenguajes son semánticamente iguales, solo cambia la sintáxis. De hecho usan el mismo compilador.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 17
Ha aumentado su posición en 3 puestos en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por xavi (7 intervenciones) el 07/03/2019 13:44:53
Si si Agustín, descargé el archivo. en xaml
y te agradezco mucho el tiempo que tomaste en contestar de verdad que lo he leido y provado el código

Creo que tampoco entendiste tu muy bien mis inquietudes, porque no puse como se hace un array de controles
sino, porque Microsoft lo ha eliminado, cual era el motivo, si se olvidó o lo estudiaron determinadamente y la
mejor opción es la de ahora, la que me estais poniendo ejemplos.

También te diré una cosa, no he programado en otros lenguajes, a lo mejor es que solo vb6 tenia lo de los
index y ningún otro lenguaje de programación los utiliza y tengo que cambiar el chip yaaaaa y olvidarme de
que se programar...

Muchas gracias de verdad
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 145
Ha mantenido su posición en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por Agustin (24 intervenciones) el 07/03/2019 14:45:04
Los paradigmas de programación cambiaron enormemente desde hace 20 años cuando se usaba Visual Basic.

No solo en lo que se refiere a GUI, sino en la forma de construir software, la separacion en capas, los paradigmas OOP y FP, el uso de abstracciones para simplificar las dificultades técnicas.

Por ejemplo, en VB se suele tirar instrucciones SQL escritas a mano, mientras que en .NET se suelen usar ORMs como NHibernate o Entity Framework, que permiten abstraer la lógica de acceso a datos y usar un modelo estatico (fuertemente tipado) para consultar y operar con las tablas de una base de datos.

Lo mismo en la GUI. Los paradigmas modernos son declarativos en lugar de imperativos. No existe el concepto de "crear controles", sino que se declara la forma en la que se ven los elementos en pantalla, y se declara una estructura de datos que represente lo que se está mostrando. En el caso del calendario, lo que se está mostrando son meses, o de hecho, fechas del 1/1/{año} hasta el 31/12/{año}, agrupadas por mes. Esto es lo que muestra mi ejemplo, como operar con DATOS en lugar de "controles" y luego hacer que los elementos visuales se manifiesten como meras representaciones visuales de dichos datos. Fijate que el codigo C# (la parte imperativa) de mi ejemplo NO hace referencia a botones, ni cuadros, ni ningun elemento visual, sino que trabaja con fechas, dias de la semana, agrupamiento en meses, etc.

Creo que esa es la explicacion de por qué muchas de las cosas que se usaban con paradigmas y tecnologías de hace 20 años ya no existen.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 17
Ha aumentado su posición en 3 puestos en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por xavi (7 intervenciones) el 07/03/2019 15:10:22
Gracias Agustin
Una respuesta muy técnica y coherente
Recibe un fuerte abrazo.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar
Imágen de perfil de Phil Rob
Val: 2.160
Oro
Ha mantenido su posición en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por Phil Rob (531 intervenciones) el 07/03/2019 12:32:33
Hola Xavi,

Sobre los 20 botones ...
Claro que no tiene que escribir 20 procedimientos para responder al Click de los 20 botones.

Es possible de escribir un solo procedimiento con 20 Handles, pero es aun muy incomodo (ej. 1) :
1
2
3
Private Sub Boton_Click(ByVal sender As Object, ByVal e As EventArgs) Handles Button1.Click, Button2.Click ' ......hasta  Button20, 
        MessageBox.Show(sender.Text)  ' para probar
    End Sub

Es mejor de escribir un solo procedimiento y de agregar los handles de manera dinamica (ej. 2) :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Private Sub FMuchoBotons_Load(ByVal sender As Object, ByVal e As EventArgs) Handles Me.Load
        For Each Control In Me.Controls
            If TypeOf Control Is Button Then
                Dim Btn As Button = CType(Control, Button)
                If Btn.Name.StartsWith("Button") Then
                    AddHandler Btn.Click, AddressOf Me.Boton_Click
                End If
            End If
        Next
    End Sub
 
    Private Sub Boton_Click(ByVal sender As Object, ByVal e As EventArgs)
        MessageBox.Show(sender.Text) ' para probar
    End Sub

Que tenga un buen dia
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar

El porque de las cosas. Necesito un guía. Por favor

Publicado por Nacho (30 intervenciones) el 07/03/2019 14:03:47
En .net todo control, incluido un form, contiene la propiedad ControlCollection que representa la colección de controles incluidos en el control.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar
sin imagen de perfil
Val: 17
Ha aumentado su posición en 3 puestos en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por xavi (7 intervenciones) el 07/03/2019 15:17:11
Ahora mismo estoy en una situación un poco incomoda ya que después de tantos años programando en vb6
un pequeño salto a .net parece un un salto al Everest. y solo pensar en la gran cantidad de código escrito y
softwares de gestión creados y aunque no os lo creáis "por el mito de que vb6 es una mierda"
para medianas y grandes empresas y funcionales al 100% sin queja alguna,

Conexiones a sql server con millones de registros, geolocalizaciones en mapas con latitud y longitud, trazalibidad,
lectores de codigos de barras, lectores de biometria, control de stock, posicionamientos, etiquetas, mails, xml,
PDA's con codebar e imager, detectores de Caller ID, ufff un sin fin de cosas en serio.

No hablo de cosas pequeñas, con VB6 e logrado cosas insospechadas pero que funcionan y ahora me veo
en la dilema de hacer lo mismo pero en .net. y eso es el porque de las cosas. No me veo capaz de reconvertirlo todo a .net.
para conseguir lo mismo pero en .net


Muchas gracias y un abrazo a todos compañeros.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

El porque de las cosas. Necesito un guía. Por favor

Publicado por Nacho (30 intervenciones) el 07/03/2019 15:23:52
Yo la única diferencia que veo entre vb6 y .net, sea c# o vb, es que las librerías de vb6 las diseñó microsoft, demasiado parecidas a las mfc, mientras que para hacer las de .net contrataron a los que diseñaron las de delphi, y están muchísimo mejor hechas, mejor estructuradas, más lógicas y eficientes. Es hacerse a los cambios y ya está, y a lo mejor se hace uno fácilmente.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar
Imágen de perfil de gilman
Val: 222
Bronce
Ha mantenido su posición en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por gilman (70 intervenciones) el 07/03/2019 15:47:50
La conversión de un proyecto VB6 a VBNet, es practicamente imposible, salvo que sea muy simple, de eso se encargo Microsoft, sus razones tendría pero es así, con VB 2003 y VB 2005, existe la posibildad de 'migrar' un proyecto de VB6 a VBNet, pero el código migrado tiene tantos errores y warnings, que resulta imposible corregirlo, hasta el extremo de que, en la mayoría de los casos, es preferible escribir todo el código de 0, y no es solo por el tema de componentes Com de terceros, con los mismos controles intrinsecos de VB, Textbox, Label,... da problemas ya que si, en alguna sentencia, se usan las propiedades por defecto, marca dichas sentencias como erroneas, vamos que Microsoft decidió deshacerse de VB6 y, me da la impresión, de VBNet a la vez.
Existen productos que dicen migrar la mayor parte de los proyectos, pero no sé que resultado darán.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
2
Comentar
Imágen de perfil de Phil Rob
Val: 2.160
Oro
Ha mantenido su posición en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por Phil Rob (531 intervenciones) el 07/03/2019 17:56:35
Dices " ... conversión de un proyecto VB6 a VBNet, es practicamente imposible, salvo que sea muy simple..."

Esta la realidad. He probado en 2005 ...
Finalmente, he creado los formularios DotNet en imitando aquellos de VB6, después he trabajado uno procediemento a vez en adaptado su codigo (a menudo, ello es todo reescribir).
Entonces, hay tambien las modificaciónes "invisibles" (ej. no hay más RecordSet, ahora es DataSet y las herramientas de acceso a la base de datos no son las mismas). ¡Que trabajo! Nuca más ...
Mejor es todo reescribir, quizá solo inspirarse de la antigua aplicación.

Saludos
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar
sin imagen de perfil
Val: 145
Ha mantenido su posición en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por Agustin (24 intervenciones) el 07/03/2019 16:59:13
No se trata de que VB6 "sea una mierda" sino que es una plataforma que era adecuada para un mundo de hace 20 años atras, que ya no existe.

Yo también he hecho muchísimas cosas complejas en VB6, pero ya hace 10 años me pase a .NET y jamás volví a mirar atras.
La realidad es que cualquier cosa que hagas en VB6, en .NET lo podes hacer muchisimo más fácil, principalmente por las abstracciones que te mencioné antes.

Te doy un ejemplo concreto: en .NET, con unas 20 lineas de codigo y usando un framework llamado NHibernate, podes crear una abstraccion que te permita ejecutar cualquier consulta, en cualquier tabla, vista o join complejo, presente o futuro, de cualquier base de datos, presente o futura, de cualquier motor de SQL (y no-SQL también), presente o futuro, usando un modelo estático, en cualquier proyecto, presente o futuro, en cualquier lugar, para siempre, SIN ESCRIBIR UNA SOLA LINEA DE SQL.

Esto sencillamente es imposible de lograr en VB6, principalmente porque el umbral de abstracción de VB6 es muy limitado comparado con el de .NET.

Te darás cuenta que con esta clase de herramientas a tu disposición, cualquier desarrollo que puedas plantear se facilita y se reduce el esfuerzo terriblemente. No solo para la construcción inicial de un proyecto, sino para el mantenimiento. Porque claramente es muchísimo más fácil mantener una abstracción de 20 líneas de código y un modelo de datos estático (con todo lo que eso implica en términos de facilidad de refactor, soporte de tooling, etc) que mantener cientos o miles de consultas SQL escritas como strings dentro de tu código. La flexibilidad y facilidad de adaptación a los cambios, junto con la robustez, y sobre todo la productividad que me da .NET no me la da ninguna otra plataforma de software que haya utilizado jamás. Por eso apuesto el futuro de mi empresa sobre este stack de tecnología.

Otro aspecto en el que el mundo ha cambiado muchísimo desde los 80's y 90's es en la interconectividad del software. Hoy por hoy los proyectos de software empresarial necesitan estar integrados con otros sistemas y proveer facilidad de integración para que otros sistemas (presentes o futuros) puedan interactuar con la lógica y las reglas de negocio de tu sistema. Esto es enormemente más difícil con VB6 que con .NET, ya que (de nuevo) las abstracciones que provee VB6 no son suficientes. Además, el mundo de los 90's en donde uno tenía que utilizar si o si una PC para acceder a la información ha quedado atras, y hoy por hoy el software empresarial necesita poder funcionar en dispositivos móviles, tablets, a traves de internet, donde sea.

Con todo esto, nadie dice que VB6 sea "una mierda", pero entenderás que para la mayoría de desarrolladores experimentados, VB6 dejó de ser una opción viable para proveer soluciones de negocios, hace mucho, mucho tiempo.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
1
Comentar
sin imagen de perfil
Val: 17
Ha aumentado su posición en 3 puestos en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por xavi (7 intervenciones) el 07/03/2019 18:05:43
Joer Agustín eres un maestro del NET

Si me dejas abusar un poco de tu sabiduría.
Porque es tan necesario utilizar la libreria NHibernate para hacer aplicaciones de gestión de datos?
Con los dataset datareader datatable, etc que trae el mismo net, no seré capaz de hacer
una aplicación decente?


Estoy mal acostumbrado por que yo siempre me a gustado trabajar con codigo a pelo, en vb6
nunca utilice el objeto data ni la opcion de conectar directamente a la db, todo lo hacia
a través de codigo y manipular en todo momento lo que hago.

'**** El resto es un suplemento si no quieres seguir leyendo no es primordial *****

Esto es un ejemplo de mi forma de programa, para bien o para mal, pero funciona perfecto y rápido...

Para la conexion a sql desde el exterior en un Modulo

1
2
3
4
5
Public Basedatos AS New ADODB.Connection
Basedatos.ConnectionTimeout = 30 'tiempo de espera en conectar a la base de datos
Basedatos.CommandTimeout = 20 'tiempo de espera en las consultas
Basedatos.CursorLocation = adUseClient
Basedatos.Open "Provider=SQLNCLI11; SERVER=IPServidor; Database=DB; User Id=x; Password=x;"

y para las tablas

1
2
3
4
5
6
Dim Registros as new adodb.recordset
Registros.Open "SELECT top 1 * FROM clientes WHERE codigo = '" & Valor & "'", Basedatos, adOpenKeyset, adLockOptimistic
Registros.addnew
Registros("Nombre") = "xxxx"
Registros.update
Registros.close
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil
Val: 145
Ha mantenido su posición en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por Agustin (24 intervenciones) el 08/03/2019 06:42:40
Vamos por partes:

> Porque es tan necesario utilizar la libreria NHibernate para hacer aplicaciones de gestión de datos?

> Con los dataset datareader datatable, etc que trae el mismo net, no seré capaz de hacer
una aplicación decente?

"necesario", estrictamente necesario no hay nada. ¿Podrías hacer una aplicacion decente usando solo lenguaje ensamblador? por supuesto que sí, si te tomas el tiempo y el esfuerzo necesario.

Las herramientas y abstracciones sirven justamente para reducir el tiempo y el esfuerzo necesario para realizar un trabajo determinado.
¿Por qué no es viable construir un software de negocios para una empresa utilizando solo lenguaje ensamblador? Pues porque para hacerlo necesitarías miles de horas de trabajo y un equipo de decenas de personas, y no es viable económicamente, ni tampoco razonable.

Cuanto más alto es el umbral de abstracción de un desarrollador, y de las herramientas que utiliza, mayor es la productividad y menos esfuerzo requiere para construir software. Es conocido el caso de Yan Cui, que utilizando el paradigma funcional y el lenguaje F#, reemplazó a un equipo entero de 5 programadores java. Es decir, una sola persona (con las herramientas correctas y el conocimiento) haciendo el trabajo que antes hacían 5.

Esto mismo pasa cuando comparas .NET con VB6. Como te dije antes, el umbral de abstracción de .NET es enormemente superior al de VB6.

Hagamos el ejercicio mental de comparar tu ejemplo de código con cómo lo haria yo en .NET usando NHibernate (u otro ORM, como Entity Framework, el código es muy similar).

1
2
3
var cliente = _session.Query<Cliente>().FirstOrDefault(x => x.Codigo == valor);
cliente = new Cliente { Nombre = "xxxx" };
_session.SaveOrUpdate(cliente);

A simple vista te puedo nombrar estas ventajas de este código respecto de tu ejemplo:

1 - utiliza un modelo estático, que es verificado por el compilador en tiempo de compilación. Es decir, qué sucede si mañana eliminamos la columna "Codigo" de la tabla cliente?
- En tu ejemplo, tendríamos que revisar todo el sistema completo buscando lugares donde se utilice la columna, y puede ser que haya muchos falsos positivos. Si haces una búsqueda de texto por "Codigo", pero resulta que todas las tablas de tu base tienen una columna con ese nombre, vas a tener que revisar todo el proyecto y eso te va a llevar muchísimo tiempo.
- En mi ejemplo, hay una clase Cliente declarada en el modelo, y esa clase tiene properties que representan las columnas de la tabla cliente, con sus respectivos tipos de datos. Si yo decidiera borrar la columna, simplemente borraría la property correspondiente de la clase, y el compilador me daría exactamente una lista de todos los lugares del proyecto entero donde se usa esa property, para corregir. Como el compilador sabe que la clase Cliente y Producto NO son iguales, no confundiría Cliente.Codigo con Producto.Codigo, con lo cual no me daria falsos positivos.
Lo mismo sucede con el campo "Nombre". O sea como es un string, es responsabilidad del desarrollador verificar que este escrito correctamente, y además "recordar" cuales son los campos válidos de esa tabla. No tenés intellisense, no tenés ninguna herramienta del IDE para ayudarte, con lo cual tenes que estar "adivinando" todo todo el tiempo. Vos podrás decir "ah, yo me acuerdo", pero no estás considerando que el software se construye con equipos de personas, y lo que "vos te acordas", otra persona puede no saberlo o no acordarse. En lugar de obligar a todo el equipo a memorizar detalles irrelevantes, lo que hacemos es usar herramientas más modernas y dejar que el equipo se concentre en diseñar y construir lógica de negocio.

2 - No estoy utilizando strings en ningun lado. Los strings no los verifica el compilador, con lo cual es muy facil que cometas un typo, como escribir SLEECT en lugar de SELECT, o escribir mal el nombre de una columna. La única forma de comprobar esto, es ejecutar el programa y probar, lo cual es una pérdida de tiempo. Además, en particular tu código es vulnerable a ataques de inyección SQL, mientras que el mío no.

3 - En tu ejemplo, los tipos de datos están implícitos y hay que adivinarlos y recordarlos. Por ejemplo, el WHERE Codigo = '' asume que código es VARCHAR. Qué sucedería si dentro de 3 meses se decide cambiar esa columna a INT? Otra vez lo mismo que en el punto #1, te verías obligado a recorrer todo el código buscando los lugares donde hacer las correcciones.

4 - Tu código no se puede abstraer, ni reutilizar. Solo sirve para consultar la tabla Clientes y solo para filtrar por el campo Codigo. Si yo quisiera reutilizarlo para otras tablas/columnas, tendría 2 opciones:
A - copy/paste. Esto es muy poco mantenible, ya que si luego hubiera un error o surgiera la necesidad de introducir una mejora, habría que modificar el código tantas veces como se haya copiado y pegado. Si tenes 100 tablas, y 100 funciones copy/pasteadas que solo varian en el nombre de la tabla, para introducir una mejora en todos los casos tendrías que modificar 100 funciones diferentes.
B - pasar el nombre de la tabla/columna como parametro de tipo "string". Esto se conoce como String Typing, y es un abuso del uso de strings donde en realidad se deberían usar otros tipos de datos. Es decir, si yo tengo un parametro de tipo string tranquilamente podria recibir cualquier valor de string, incluyendo nombres que no correspondan a tablas reales de la base de datos, o nombres de tablas que en realidad no tienen el campo Codigo para la consulta. De nuevo, como es un simple string el compilador no tiene idea de si tu codigo es correcto o no. Queda en cada desarrollador la responsabilidad de verificar esto. Esto se conoce como "compilador humano", ya que en realidad estás haciendo vos mismo la tarea del compilador.

En mi ejemplo, si yo cambio el tipo <Cliente> por otro, el codigo dejaría de compilar si paso un tipo inválido (que no sea una entidad de la base de datos, por ejemplo), o si paso una entidad que no tenga el campo "Codigo". El compilador se encarga de verificar que mi codigo sea correcto, para que no tenga que hacerlo yo mismo.
Asimismo, si quisiera generalizar ese codigo simplemente tendria que reemplazar el tipo concreto <Cliente> por un tipo <T> y usar Generics de .NET para poder reutilizar mi codigo infinitamente con cualquier entidad, presente o futura.

5 - Otro aspecto en el que me resulta insuficiente la abstracción es que en tu ejemplo, para relacionar tablas, hay que conocer los foreign keys de cada una, recordar los nombres. No hay intellisense, no hay nada que te ayude. De nuevo, no se trata de vos te los sabes o no ahora mismo, pensá qué pasaría si una persona tiene que encargarse de hacer mantenimiento a tu código. Esa persona bien podrías ser vos mismo dentro de unos meses.

Usando un ORM, en cambio, podes hacer consultas como esta:
1
2
3
4
5
6
7
8
var cuotas =
                _session.Query<Cuota>()
                    .Where(x => x.PlanPagos.Estado == PlanPagos.OptionSets.Estado.Activo)
                    .Where(x => x.Operacion.Estado == Operacion.OptionSets.Estado.Activo)
                    .Where(x => x.Estado == Cuota.OptionSets.Estado.Activo)
                    .Where(x => x.RazonParaElEstado == Cuota.OptionSets.RazonParaElEstado.CanceladoTotalmente)
                    .Where(x => x.Anio == dto.Anio && x.Mes == dto.Mes)
                    .Where(x => x.SaldoConcepto > 0);

Esa consulta involucra 3 tablas: Cuotas, PlanPagos, y Operacion. Fijate que en ningún lado necesité referenciar los foreign keys, sino que me concentro en la lógica de negocio. Además en esta consulta podes ver otra ventaja: el uso de Enums. La columna Estado de las 3 tablas es de tipo INT, pero solo hay un puñado de valores válidos para cada caso. El ORM me asegura que le estoy pasando un valor valido para cada caso, y el compilador sabe que Operacion.Estado es diferente de Cuota.Estado, con lo cual no me va a permitir confundirme uno con otro. Y lo que te decía antes de los tipos de los parámetros de la consulta: el compilador sabe que Cuota.Anio y Cuota.Mes son de tipo INT, con lo cual no me va permitir hacer algo como (x.Anio > "holacomoestas"), eso va a ser un error de compilación.

6 - Grafo de objetos: asi como dentro de la consulta yo pude hacer cuota.Operacion.PlanPagos y resolver las relaciones entre las tablas, fuera de la consulta tambien lo puedo hacer. Esto se conoce como "lazy load", y significa que si yo tengo una Cuota, al acceder a la propiedad Operacion el ORM se encarga de ir a la base de datos y buscar el registro, sin que yo tenga que hacer queries adicionales. Lo mismo ocurre en el Save() o en el Update()

Podria seguir, pero son las 2:40 AM y tengo sueño.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
2
Comentar
sin imagen de perfil
Val: 17
Ha aumentado su posición en 3 puestos en Visual Basic.NET (en relación al último mes)
Gráfica de Visual Basic.NET

El porque de las cosas. Necesito un guía. Por favor

Publicado por xavi (7 intervenciones) el 08/03/2019 08:50:09
+10

Madre mía Agustín cuanta sabiduría junta.

Si conociera a alguien como tu cerca de mi casa, seguro que se me va el miedo al .net en poco tiempo
y no como ahora que llevo años dándole vueltas y haciendo pruebas. Pero es que lo que sabia de .net
con tu mensaje anterior veo que aun no se nada, y eso que las PDA las programé en .net.

Bueno ufff !!! me pasaría horas hablando contigo

De todas formas, aprovecharé todo lo que me has dicho y los demás compañeros del foro también
como referencia para continuar mi aprendizaje pero con los conocimientos que me habéis brindado.

Personas como vosotros que ofrecen su ayuda ("mucha ayuda") sin animo de lucro, no tiene precio.

Yo no estoy a vuestra altura para ofreceros mi ayuda, pero si alguna vez pasáis por Lleida estáis
invitados a una cena, "una cena muuuy larga por eso, que hay muuucho de que hablar jejeje"

Muchas gracias de verdad sois los mejores
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar