Migración a ASP .NET: consideraciones clave

Cambios en el lenguaje Visual Basic

Tal y como se ha mencionado anteriormente, VBScript ha desaparecido en favor de Visual Basic .NET, más completo y eficaz. En este apartado resaltaré algunos de los problemas con los que probablemente se encuentre relacionados con los cambios en el lenguaje Visual Basic. Es importante aclarar que esta lista no pretende abarcar todos los cambios realizados en Visual Basic. En realidad se centra en los elementos que con más probabilidad se encontrará un programador de ASP/VBScript que migre a ASP .NET utilizando Visual Basic .NET. Consulte la documentación de Visual Basic .NET si desea una lista completa de todos los cambios realizados en el lenguaje.

Desaparición del tipo de datos Variant

Lo conocemos, nos encanta y se convierte en una pesadilla que nos fascina. Por supuesto, me refiero a un tipo de datos VARIANT. Este tipo de datos no forma parte de .NET y, por lo tanto, Visual Basic .NET no lo admite. La consecuencia es que todas sus variables ASP, que ahora son del tipo VARIANT, se van a convertir sigilosamente en variables de tipo Object. La mayoría de las variables que emplee su aplicación pueden y deben transformarse en el correspondiente tipo anterior en función de sus necesidades. En caso de que la variable sea realmente un tipo object en términos de Visual Basic, en ASP .NET basta con declararla explícitamente como un tipo Object.

Tipos de datos en Visual Basic

Un tipo VARIANT que merece especial atención es VT_DATE, que en Visual Basic aparece como Date. En Visual Basic, un tipo Date se almacena en un formato doble que utiliza cuatro bytes. En Visual Basic .NET, Date utiliza el tipo Common Language Runtime DateTime, que se representa con un número entero de ocho bytes.

Puesto que en ASP todo es VARIANT, las variables Date que elija se compilarán y continuarán funcionando según cómo se utilicen. No obstante, es posible que surjan algunos problemas inesperados al ejecutar ciertas operaciones con la variable debido a que el tipo subyacente ha sido modificado. Preste atención a las áreas donde pase el valor Date a objetos COM en forma de valores enteros largos o al realizar algunas operaciones de conversión en tipos de datos utilizando CLng.

La opción Explicit es ahora la predeterminada

En ASP, las palabras clave Option Explicit estaban disponibles pero no eran las predeterminadas. Esto ha cambiado en Visual Basic .NET. Dado que ahora Option Explicit es la opción predeterminada, se hace necesario declarar todas las funciones. Una práctica aconsejable consiste en ser incluso más estricto y cambiar la configuración a Option Strict. De este modo, se deberán declarar todas las variables como un tipo de datos específico. A pesar de que esta acción pueda parecer más laboriosa, en realidad es el modo en que se debería trabajar. Si no se selecciona esta opción, la calidad del código empeorará, ya que todas las variables no declaradas se convertirán en tipos Object. La mayoría de las conversiones implícitas seguirán funcionando, pero resulta más seguro declarar explícitamente todas las conversiones al tipo que deseemos.

LET y SET ya no se pueden utilizar

Los objetos se pueden asignar directamente de uno a otro del siguiente modo: MyObj1 = MyObj2. Ya no es necesario emplear las instrucciones SET o LET. Si utiliza estas instrucciones, tendrán que ser eliminadas.

Uso de paréntesis en las llamadas a métodos

En ASP, se pueden realizar con total libertad llamadas a métodos en objetos sin utilizar paréntesis, como ilustra el siguiente ejemplo:

Sub WriteData()
   Response.Write "This is data"
End Sub
WriteData

En ASP .NET, hay que incluir paréntesis en todas las llamadas, incluso en aquellos métodos que carezcan de parámetros. Escribir el código como en el siguiente ejemplo permite que funcione correctamente tanto en ASP como en ASP .NET.

Sub WriteData()
   Response.Write("This is data")
End Sub
Call WriteData()

ByVal es ahora el valor predeterminado

En Visual Basic, todos los argumentos de parámetros se pasaban, de manera predeterminada, por referencias o ByRef. En Visual Basic .NET, todos los argumentos se pasan de manera predeterminada por el valor o ByVal. Si desea conservar el comportamiento "ByRef", utilice de forma explícita la palabra clave ByRef delante de los parámetros como se muestra en el siguiente ejemplo:

Sub MyByRefSub (ByRef Value)
   Value = 53;
End Sub

En este punto hay que ser extremadamente cuidadoso. En el momento de migrar el código a ASP .NET, es recomendable que se verifiquen dos y tres veces cada parámetro utilizado en las llamadas a métodos para asegurarse de que este cambio es realmente el que deseamos. Probablemente tendrá que cambiar algunos de ellos.

Desaparición de las propiedades predeterminadas

El concepto de propiedad predeterminada ha desaparecido en Visual Basic .NET. Esto significa que si se tiene código ASP que depende de una propiedad predeterminada proporcionada por uno de sus objetos, deberá referirse explícitamente a la propiedad deseada, como se muestra en el siguiente código:

'Sintaxis de ASP (recuperación implícita de la propiedad Column Value)
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("TestDB")
Set RS = Conn.Execute("Select * from Products")
Response.Write RS("Name")

'Sintaxis de ASP.NET (recuperación explícita de la propiedad Column Value)
Conn = Server.CreateObject("ADODB.Connection")
Conn.Open("TestDB")
RS = Conn.Execute("Select * from Products")
Response.Write (RS("Name").Value)

Cambios en tipos de datos

En Visual Basic .NET, los valores enteros son ahora de 32 bits y los caracteres extendidos han pasado a tener 64 bits.

Los problemas pueden surgir al invocar métodos en objetos COM de ASP .NET o al realizar llamadas a Microsoft® Win32® API dentro de los componentes personalizados de Visual Basic. Preste especial atención al tipo de datos real necesario para garantizar que sus valores se pasen o conviertan correctamente.

Control de excepciones estructurado

Aunque las conocidas técnicas de control de errores On Error Resume Next y On Error Goto se siguen admitiendo en Visual Basic .NET, han dejado de ser la mejor forma de trabajar. Visual Basic posee ahora un auténtico sistema de control de excepciones estructurado que utiliza las palabras clave Try, Catch y Finally. Si se puede, se debería cambiar a este nuevo modelo de control de errores porque proporciona un mecanismo más eficaz y coherente de solucionar los errores de la aplicación.

LO ÚLTIMO en tu Correo. Suscríbete Gratis a NUESTRO BOLETÍN !!

Te Agradeceríamos nos informes si encuentras un ENLACE ROTO