Professional Documents
Culture Documents
En este curso se tratan todas las cuestiones fundamentales que le permitirán crear
aplicaciones web con Visual Studio 2005. Al final del curso sabrá todo lo necesario
para crear sus propias aplicaciones Web orientadas a datos y con multitud de
características avanzadas.
En realidad .NET es mucho más que eso ya que ofrece un entorno gestionado de
ejecución de aplicaciones, nuevos lenguajes de programación y compiladores, y
permite el desarrollo de todo tipo de funcionalidades: desde programas de consola o
servicios Windows hasta aplicaciones para dispositivos móviles, pasando por
desarrollos de escritorio o para Internet. Son estos últimos de los que nos
ocuparemos en este curso. Pero antes conviene conocer los fundamentos en los que
se basa cualquier aplicación creada con .NET, incluyendo las que nos interesan.
.NET ofrece un entorno de ejecución para sus aplicaciones conocido como Common
Language Runtime o CLR. La CLR es la implementación de Microsoft de un estándar
llamado Common Language Infrastructure o CLI. Éste fue creado y promovido por la
propia Microsoft pero desde hace años es un estándar reconocido mundialmente por
el ECMA.
Lo mejor de todo es que cualquier componente creado con uno de estos lenguajes
puede ser utilizado de forma transparente desde cualquier otro lenguaje .NET.
Además, como ya se ha comentado, es posible ejecutar el código .NET en diferentes
plataformas y sistemas operativos.
Cuando se compila una aplicación escrita en un lenguaje .NET cualquiera (da igual
que sea VB, C# u otro de los soportados), el compilador lo que genera en realidad es
un nuevo código escrito en este lenguaje intermedio. Así, todos los lenguajes .NET se
usan como capa de más alto nivel para producir código IL.
Cada lenguaje .NET utiliza una sintaxis diferente para cada tipo de datos. Así, por
ejemplo, el tipo común correspondiente a un número entero de 32 bits
(System.Int32) se denomina Integer en Visual Basic .NET, pero se llama int en C#.
En ambos casos representan el mismo tipo de datos que es lo que cuenta.
Nota:
En ASP 3.0 se suele usar VBScript como lenguaje de programación. En
este lenguaje interpretado, al igual que en VB6, un Integer representaba
un entero de 16 bits. Los enteros de 32 bits eran de tipo Long. Es un
fallo muy común usar desde Visual Basic .NET el tipo Integer pensando
que es de 16 bits cuando en realidad es capaz de albergar números
mucho mayores. Téngalo en cuenta cuando empiece a programar.
Existen tipos por valor (como los enteros que hemos mencionado o las
enumeraciones) y tipos por referencia (como las clases). En el siguiente módulo se
profundiza en todas estas cuestiones.
Resulta muy útil para comprender lo explicado hasta ahora. No se preocupe si hay
elementos que no conoce, más adelante los estudiaremos todos.
Dada la ingente cantidad de clases que existen debe haber algún modo de
organizarlas de un modo coherente. Además hay que tener en cuenta que podemos
adquirir más funcionalidades (que se traducen en clases) a otros fabricantes, por no
mencionar que crearemos continuamente nuevas clases propias.
Para solucionar este problema existen en todos los lenguajes .NET los espacios de
nombres o namespaces.
Si usted ha programado con Visual Basic 6.0 o con ASP, ha empleado en su código
con total seguridad la interfaz de acceso a datos conocida como ADO (ActiveX Data
Objects), puede que combinado con ODBC (Open Database Connectivity). Si además
es usted de los programadores con solera y lleva unos cuantos años en esto es
probable que haya usado RDO o incluso DAO, todos ellos métodos mucho más
antiguos.
ADO.NET ofrece una funcionalidad completamente nueva, que tiene poco que ver con
lo existente hasta la fecha en el mercado. Sin embargo, con el ánimo de retirar
barreras a su aprendizaje, Microsoft denominó a su nuevo modelo de acceso a datos
con un nombre similar y algunas de sus clases recuerdan a objetos de propósito
análogo en el vetusto ADO.
El objeto más importante a la hora de trabajar con el nuevo modelo de acceso a datos
es el DataSet. Sin exagerar demasiado podríamos calificarlo casi como un motor de
datos relacionales en memoria. Aunque hay quien lo asimila a los clásicos Recordsets
su funcionalidad va mucho más allá como se verá en el correspondiente módulo.
Arquitectura de ADO.NET
El concepto más importante que hay que tener claro sobre ADO.NET es su modo de
funcionar, que se revela claramente al analizar su arquitectura:
Capa conectada
La clase DataAdapter hace uso de las tres anteriores para actuar de puente entre la
capa conectada y la desconectada.
Estas clases son abstractas, es decir, no tienen una implementación real de la que se
pueda hacer uso directamente. Es en este punto en donde entran en juego los
proveedores de datos. Cada origen de datos tiene un modo especial de
comunicarse con los programas que los utilizan, además de otras particularidades que
se deben contemplar. Un proveedor de datos de ADO.NET es una implementación
concreta de las clases conectadas abstractas que hemos visto, que hereda de éstas y
que tiene en cuenta ya todas las particularidades del origen de datos en cuestión.
Así, por ejemplo, las clases específicas para acceder a SQL Server se llaman
SqlConnection, SqlCommand, SqlDataReader y SqlDataAdapter y se
encuentran bajo el espacio de nombres System.Data.SqlClient. Es decir, al
contrario que en ADO clásico no hay una única clase Connection o Command que se
use en cada caso, si no que existen clases especializadas para conectarse y recuperar
información de cada tipo de origen de datos.
Nota:
El hecho de utilizar clases concretas para acceso a las fuentes de datos
no significa que no sea posible escribir código independiente del origen
de datos. Todo lo contrario. La plataforma .NET ofrece grandes
facilidades de escritura de código genérico basadas en el uso de herencia
e implementación de interfaces. De hecho la versión 2.0 de .NET ofrece
grandes novedades específicamente en este ámbito.
Existen proveedores nativos, que son los que se comunican directamente con el
origen de datos (por ejemplo el de SQL Server o el de Oracle), y proveedores
"puente", que se utilizan para acceder a través de ODBC u OLEDB cuando no existe
un proveedor nativo para un determinado origen de datos.
Nota:
Estos proveedores nativos, si bien muy útiles en determinadas
circunstancias, ofrecen un rendimiento menor debido a la capa
intermedia que están utilizando (ODBC u OLEDB). Un programador novel
puede sentir la tentación de utilizar siempre el proveedor puente para
OLEDB y así escribir código compatible con diversos gestores de datos
de forma muy sencilla. Se trata de un error y siempre que sea posible es
mejor utilizar un proveedor nativo.
Capa desconectada
Una vez que ya se han recuperado los datos desde cualquier origen de datos que
requiera una conexión ésta ya no es necesaria. Sin embargo sigue siendo necesario
trabajar con los datos obtenidos de una manera flexible. Es aquí cuando la capa de
datos desconectada entra en juego. Además, en muchas ocasiones es necesario tratar
con datos que no han sido obtenidos desde un origen de datos relacional con el que
se requiera una conexión. A veces únicamente necesitamos un almacén de datos
temporal pero que ofrezca características avanzadas de gestión y acceso a la
información.
Por otra parte las conexiones con las bases de datos son uno de los recursos más
escasos con los que contamos al desarrollar. Su mala utilización es la causa más
frecuente de cuellos de botella en las aplicaciones y de que éstas no escalen como es
debido. Esta afirmación es especialmente importante en las aplicaciones Web en las
que se pueden recibir muchas solicitudes simultáneas de cualquier parte del mundo.
Finalmente otro motivo por el que es importante el uso de los datos desconectado de
su origen es la transferencia de información entre capas de una aplicación. Éstas
pueden encontrarse distribuidas por diferentes equipos, e incluso en diferentes
lugares del mundo gracias a Internet. Por ello es necesario disponer de algún modo
genérico y eficiente de poder transportar los datos entre diferentes lugares, utilizarlos
en cualquiera de ellos y posteriormente tener la capacidad de conciliar los cambios
realizados sobre ellos con el origen de datos del que proceden.
Todo esto y mucho más es lo que nos otorga el uso de los objetos DataSet. Es obvio
que no se trata de tareas triviales, pero los objetos DataSet están pensados y
diseñados con estos objetivos en mente. Como podremos comprobar más adelante en
este curso es bastante sencillo conseguir estas funcionalidades tan avanzadas y
algunas otras simplemente usando de manera adecuada este tipo de objetos.
Nota:
Otra interesante característica de los DataSet es que permiten gestionar
simultáneamente diversas tablas (relaciones) de datos, cada una de un
origen diferente si es necesario, teniendo en cuenta las restricciones y
las relaciones existentes entre ellas.
Los DataSet, como cualquier otra clase no sellada de .NET, se pueden extender
mediante herencia. Ello facilita una técnica avanzada que consiste en crear tipos
nuevos de DataSet especializados en la gestión de una información concreta (por
ejemplo un conjunto de tablas relacionadas). Estas nuevas tipos clases se denominan
genéricamente DataSet Tipados, y permiten el acceso mucho más cómodo a los
datos que representan, verificando reglas de negocio, y validaciones de tipos de datos
más estrictas.
Aplicaciones Windows Forms
Las aplicaciones de escritorio son aquellas basadas en ventanas y controles comunes
de Windows que se ejecutan en local. Son el mismo tipo de aplicaciones que antes
construiríamos con Visual Basic 6 u otros entornos similares.
En la plataforma .NET el espacio de nombres que ofrece las clases necesarias para
construir aplicaciones de escritorio bajo Windows se denomina Windows Forms. Este
es también el nombre genérico que se le otorga ahora a este tipo de programas
basados en ventanas.
Windows Forms está constituido por multitud de clases especializadas que ofrecen
funcionalidades para el trabajo con ventanas, botones, rejillas, campos de texto y
todo este tipo de controles habituales en las aplicaciones de escritorio.
Visual Studio ofrece todo lo necesario para crear visualmente este tipo de programas,
de un modo similar aunque más rico al que ofrecía el entorno de desarrollo integrado
de Visual Basic.
Figura 1.4.- Diseñador de interfaces de aplicaciones de escritorio con
Windows Forms en Visual Studio 2005.
Al contrario que en VB6, .NET proporciona control sobre todos los aspectos de las
ventanas y controles, no dejando nada fuera del alcance del programador y otorgando
por lo tanto la máxima flexibilidad. Los formularios (ventanas) son clases que heredan
de la clase base Form, y cuyos controles son miembros de ésta. De hecho se trata
únicamente de código y no es necesario (aunque sí muy recomendable) emplear el
diseñador gráfico de Visual Studio para crearlas.
Este es el aspecto que presenta parte del código que genera la interfaz mostrada en
la anterior figura:
Figura 1.5.- Código autogenerado por Visual Studio para crear la interfaz de
la figura anterior.
Al contrario que en Visual Basic tradicional, en donde siempre existían instancias por
defecto de los formularios que podíamos usar directamente, en .NET es necesario
crear un objeto antes de poder hacer uso de los formularios:
Todos los controles heredan de una clase Control por lo que conservan una serie de
funcionalidades comunes muy interesantes, como la capacidad de gestionarlos en el
diseñador (moviéndolos, alineándolos...), de definir márgenes entre ellos o hacer que
se adapten al tamaño de su contenedor.
Este tipo de aplicaciones se salen del ámbito de este curso por lo que no se
profundizará más en ellas.
Aplicaciones Web Forms
Tradicionalmente las aplicaciones Web se han desarrollado siguiendo un modelo mixto
que intercalaba código HTML y JavaScript propio de páginas Web (parte cliente), junto
con código que se ejecutaría en el servidor (parte servidora). Este modelo contrastaba
por completo con el modelo orientado a eventos seguido por las principales
herramientas de desarrollo de aplicaciones de escritorio.
Hacer esto en una aplicación de escritorio no tiene mayor dificultad ya que todo el
código se ejecuta en el mismo lugar. La principal característica de las aplicaciones
Web sin embargo es que se la interfaz de usuario (lo que los usuarios de la aplicación
ven) se ejecuta en un lugar diferente al código de la aplicación que reside en un
servidor. Para mayor desgracia estas aplicaciones se basan en el uso del protocolo
HTTP que es un protocolo sin estado y que no conserva la conexión entre dos
llamadas consecutivas.
Por ejemplo, el siguiente código ilustra el código que es necesario escribir en ASP
para disponer de una página que rellena una lista de selección con unos cuantos
nombres (podrían salir de una base de datos y aún sería más complicado), y que
dispone de un botón que escribe un saludo para el nombre que se haya elegido de la
lista.
Figura 1.6.- Código ASP sencillo que genera una lista de selección y saluda al
presionar un botón.
Contenido
· Lección 5: Atributos
o Atributos
En esta primera lección veremos los tipos de datos que .NET Framework pone a
nuestra disposición, así mismo veremos las diferencias con respecto a los tipos de
datos de VBScript/VB6 y las equivalencias entre los tipos de ambos entornos, de esta
forma nos resultará más fácil familiarizarnos. Aunque no debemos olvidar que en .NET
los tipos de datos tienen un tratamiento, en algunos casos, especial que pueden
llevarnos a confusión, por tanto en los casos que pueda existir esa posibilidad de
funcionamiento diferente, veremos ejemplos de cómo los manejábamos en
VBScript/VB6 y cómo tendremos que usarlos desde Visual Basic .NET.
En los siguientes enlaces tenemos los temas a tratar en esta primera lección del
módulo sobre las características del lenguaje Visual Basic .NET
· Tipos primitivos
o Sufijos o caracteres y símbolos identificadores para los tipos
o Tipos por valor y tipos por referencia
· Variables y constantes
o Consejo para usar las constantes
o Declarar variables
o Declarar variables y asignar el valor inicial
o El tipo de datos Char
o Obligar a declarar las variables con el tipo de datos
o Aplicar Option Strict On a un fichero en particular
o Aplicar Option Stict On a todo el proyecto
o Más opciones aplicables a los proyectos
· Arrays (matrices)
o Declarar e inicializar un array
o Cambiar el tamaño de un array
o Eliminar el contenido de un array
o Los arrays son tipos por referencia
Tipos primitivos
Veamos en la siguiente tabla los tipos de datos definidos en .NET Framework y los
alias utilizados en Visual Basic 2005, así como el equivalente de VBScript/VB6.
El caso del tipo String es un caso especial, realmente un String de .NET es casi como
uno de VBScript/VB6, con la diferencia de que las cadenas en .NET son inmutables.
Esto quiere decir que una vez que se han creado no se pueden modificar, y en caso
de que queramos cambiar el contenido, .NET se encarga de usar la anterior y crear
una nueva cadena. Por tanto si usamos las cadenas para realizar concatenaciones
(unión de cadenas para crear una nueva), el rendimiento es inferior incluso al que
teníamos en VBScript/VB6. Existe una clase en .NET que es ideal para estos casos y
cuyo rendimiento es superior al de VBScript/VB6: la clase StringBuilder que ya
hemos visto someramente en un vídeo del módulo anterior.
Las últimas filas mostradas en la tabla son tipos especiales que si bien son parte del
sistema de tipos comunes (CTS) no forman parte de la Common Language
Specification (CLS), es decir la especificación común para los lenguajes "compatibles"
con .NET. Por tanto, si queremos crear aplicaciones que puedan interoperar con todos
los lenguajes de .NET, no debemos usar estos tipos como valores de devolución de
funciones ni como tipo de datos usado en los argumentos de las funciones,
propiedades o procedimientos públicos.
Los tipos mostrados en la tabla 1 son los tipos primitivos de .NET y por extensión de
Visual Basic 2005, es decir son tipos "elementales" para los cuales cada lenguaje
define su propia palabra clave equivalente con el tipo definido en el CTS de .NET
Framework. Todos estos tipos primitivos podemos usarlos tanto por medio de los
tipos propios de Visual Basic, los tipos definidos en .NET o bien como literales. Por
ejemplo, podemos definir un número entero literal indicándolo con el sufijo I: 12345I
o bien asignándolo a un valor de tipo Integer o a un tipo Sytem.Int32 de .NET. La
única excepción de los tipos mostrados en la tabla 1 es el tipo de datos Object, este
es un caso especial del que nos ocuparemos en la próxima lección.
Cuando usamos valores literales numéricos en Visual Basic 2005, el tipo de datos que
por defecto le asigna el compilador es el tipo Double. Si nuestra intención es utilizar
sin embargo un tipo de datos diferente, podemos indicarlo añadiendo una letra como
sufijo al tipo. Por ejemplo para indicar que queremos considerar un valor entero
podemos usar la letra I o el signo %, de igual forma, un valor de tipo entero largo
(Long) lo podemos indicar usando L o &, en la siguiente tabla podemos ver los
caracteres o letra que podemos usar como sufijo en un literal numérico para que el
compilador lo identifique sin ningún lugar a dudas.
El uso de estos caracteres nos puede resultar de utilidad particularmente para los
tipos de datos que no se pueden convertir en un valor doble.
Los tipos por valor son tipos de datos cuyo valor se almacena en la pila o en la
memoria "cercana", como los numéricos que hemos visto. Podemos decir que el
acceso al valor contenido en uno de estos tipos es directo, es decir se almacena
directamente en la memoria reservada para ese tipo y cualquier cambio que hagamos
lo haremos directamente sobre dicho valor. De igual forma cuando copiamos valores
de un tipo por valor a otro, estaremos haciendo copias independientes.
Por otro lado, los tipos por referencia se almacenan en el "montículo" (heap) o
memoria "lejana". A diferencia de los tipos por valor, los tipos por referencia lo único
que almacenan es una referencia (o puntero) al valor asignado. Si hacemos copias de
tipos por referencia, realmente lo que copiamos es la referencia propiamente dicha,
pero no el contenido.
Disponer de todos estos tipos de datos no tendría ningún sentido si no los pudiéramos
usar de alguna otra forma que de forma literal. Y aquí es donde entran en juego las
variables y constantes.
Siempre que tengamos que indicar un valor constante, ya sea para indicar el máximo
o mínimo permitido en un rango de valores o para comprobar el término de un bucle,
deberíamos usar una constante en lugar de un valor literal. De esta forma si ese valor
lo usamos en varias partes de nuestro código, si en un futuro decidimos que dicho
valor debe ser diferente, nos resultará más fácil realizar un solo cambio que cambiarlo
en todos los sitios en los que lo hemos usado. Además de que de esta forma nos
aseguramos de que el cambio se realiza adecuadamente y no tendremos que
preocuparnos de las consecuencias derivadas de no haber hecho el cambio en todos
los sitios que deberíamos.
Pero esto no es algo nuevo, las constantes se definen de la misma forma que en
VBScript/VB6, salvo que ahora podemos obligarnos a indicar el tipo de datos que esa
constante va a contener. Esto lo veremos en la siguiente sección.
Declarar variables
La declaración de las variables en Visual Basic 2005 se hace de la misma forma que
en VBScript/VB6/VB6, o casi, las excepciones vienen dadas, como hemos comentado
antes, de la posibilidad de obligar a definir el tipo de cada variable y de cómo
podemos definir más de una variable en una misma instrucción Dim.
Para no embrollar mucho la cosa, veamos ejemplos de cómo definir o declarar
variables siguiendo las buenas costumbres, es decir, indicando siempre el tipo de
datos de la variable.
En VB6 era posible definir más de una variable en una misma instrucción Dim, aunque
dependiendo de cómo hiciéramos esa declaración podía ser que, normalmente para
nuestro pesar, que no todas las variables fuesen del tipo que "supuestamente"
habíamos querido indicar.
Por ejemplo, con esta declaración:
Dim a, b, c As Integer
A primera vista estamos declarando tres variables de tipo Integer, pero realmente
solo declara con el tipo indicado a la última variable, las otras dos, se declaran con
tipo Variant o el tipo de datos predefinido (que es el que tiene por defecto todas las
variables en VBScript/VB6 para ASP clásico).
En Visual Basic 2005 al usar esa misma línea de código estamos declarando tres
variables de tipo Integer, esto es algo que debemos tener en cuenta, sobre todo si
nuestra intención era hacer precisamente lo que VB6, hacía, es decir, declarar dos
variables de tipo Variant y una de tipo Integer.
En Visual Basic 2005 también podemos inicializar una variable con un valor distinto al
predeterminado, que en los tipos numéricos es un cero, en las fechas es el 1 de enero
del año 1 a las doce de la madrugada (#01/01/0001 12:00:00AM#) y en la
cadenas es un valor nulo (Nothing), para hacerlo, simplemente tenemos que indicar
ese valor, tal como veremos es muy parecido a como se declaran las constantes. Por
ejemplo:
Dim a As Integer = 10
En esa misma línea podemos declarar y asignar más variables, pero todas deben
estar indicadas con el tipo de datos:
Por supuesto, el tipo de datos puede ser cualquiera de los tipos primitivos:
Aunque para que el código sea más legible, y fácil de depurar, no deberíamos mezclar
en una misma instrucción Dim más de un tipo de datos.
Nota:
Es importante saber que en las cadenas de Visual Basic 2005 el valor de
una variable de tipo String no inicializada NO es una cadena vacía como
ocurría en VBScript/VB6, sino un valor nulo (Nothing).
En Visual Basic 2005 podemos declarar valores de tipo Char, este tipo de datos es un
carácter Unicode y podemos declararlo y asignarlo a un mismo tiempo. El problema
con el que nos podemos encontrar es a la hora de indicar un carácter literal.
Si bien en VBScript/VB6 no existe el tipo de datos Char, si podemos convertir un valor
numérico en un carácter (realmente en una cadena) o bien podemos convertir un
carácter en su correspondiente valor numérico.
Dim c As String
c = Chr(65)
Dim n As Integer
n = Asc("A")
En Visual Basic 2005 también podemos usar esas mismas funciones, aunque en el
caso de Chr, el valor que devuelve esta función es un valor de tipo Char, no de tipo
String como ocurre en VBScript/VB6, pero debido a que un valor de tipo Char se
puede convertir en una cadena, podemos hacer una asignación como la mostrada en
el código anterior sin ningún tipo de problemas.
No debemos confundir Option Strict con el clásico Option Explicit de VB. Este
último, al igual que en VBScript/VB6, nos obliga a declarar todas las variables,
mientras que el primero lo que hace es obligarnos a que esas declaraciones tengan un
tipo de datos.
Tanto una como la otra tienen dos estados: conectado o desconectado dependiendo
de que agreguemos On u Off respectivamente.
Como recomendación para buenas prácticas, debemos "conectar" siempre estas dos
opciones, si bien Option Explicit On ya viene como valor por defecto, cosa que no
ocurre con Option Strict, que por defecto está desconectado.
En la Figura 2 mostrada anteriormente tenemos una captura del editor de Visual Basic
2005 en la que hemos indicado que queremos tener comprobación estricta.
También podemos hacer que Option Strict funcione igual que Option Explicit, es decir,
que esté activado a todo el proyecto, en este caso no tendríamos que indicarlo en
cada uno de los ficheros de código que formen parte de nuestro proyecto, si bien
solamente será aplicable a los que no tengan esas instrucciones. Aclaremos esto
último: si Option Strict (u Option Explicit) está definido de forma global al proyecto,
podemos desactivarlo en cualquiera de los ficheros, para ello simplemente habría que
usar esas declaraciones pero usando Off en lugar de On. De igual forma, si ya está
definido globalmente y lo indicamos expresamente, no se producirá ningún error. Lo
importante aquí es saber que siempre se usará el estado indicado en cada fichero,
independientemente de cómo lo tengamos definido para el ámbito del proyecto.
Para que siempre se usen estas asignaciones en todo el proyecto, vamos a ver cómo
indicarlo en el entorno de Visual Studio 2005.
Abrimos Visual Studio 2005 y una vez que se haya cargado, (no hace falta crear
ningún nuevo proyecto, de este detalle nos ocuparemos en breve), seleccionamos la
opción Herramientas>Opciones... se mostrará un cuadro de diálogo y del panel
izquierdo seleccionamos la opción Proyectos y soluciones, la expandimos y
seleccionamos Valores predeterminados de VB y veremos ciertas opciones, tal
como podemos comprobar en la Figura 2.2:
Figura 2.2. Opciones de proyectos (opciones mínimas)
Nota:
La figura mostrada corresponde a la versión Visual Web Developer de
Visual Studio. El contenido de su pantalla variará dependiendo de la
versión de Visual Studio 2005 de la que disponga.
Nota:
Aunque en esta captura muestre: C:\vbexpB1 en Default project
location, salvo que lo cambiemos, aparecerá el path por defecto dentro
de Mis documentos.
Como podemos observar, aparecen pocas opciones, si bien podemos hacer que se
muestren todas las disponibles, para hacerlo, debemos marcar la casilla que está en
la parte inferior izquierda en la que podemos leer: Mostrar todas las
configuraciones, al seleccionar esa opción nos mostrará un número mayor de
opciones, tal como podemos ver en la Figura 2.3:
Figura 2.3. Opciones de proyectos (todas las opciones)
Figura 2.4. Aviso de Option Strict al declarar una variable sin tipo
Nota:
Una de las ventajas del IDE (Integrated Development Environment,
entorno de desarrollo integrado) de Visual Studio 2005 es que nos avisa
al momento de cualquier fallo que cometamos al escribir el código, este
"pequeño" detalle, aunque alguna veces puede llegar a parecer
fastidioso, nos facilita la escritura de código, ya que no tenemos que
esperar a realizar la compilación para que tengamos constancia de esos
fallos.
En Visual Basic 2005 las enumeraciones pueden ser de cualquier tipo numérico
entero, incluso enteros sin signo, aunque el valor predefinido es el tipo Integer.
Enum Colores
Rojo
Verde
Azul
End Enum
Verde
Azul
End Enum
En este segundo caso, el valor máximo que podemos asignar a los miembros de una
enumeración será el que pueda contener un tipo de datos Long.
<Flags()> _
Rojo = 1
Verde = 2
Azul = 4
End Enum
Nota:
Los atributos los veremos con más detalle en otra lección de este mismo
módulo.
Como hemos comentado, las enumeraciones son constantes con nombres, pero esta
definición se queda algo corta. De hecho, podemos saber "el nombre" de un valor de
una enumeración, para ello tendremos que usar el método ToString, (el cual se usa
para convertir en una cadena cualquier valor numérico).
Por ejemplo, si tenemos la siguiente asignación:
Una vez aclarado este comportamiento de las enumeraciones en Visual Basic 2005,
veamos que es lo que ocurre cuando sumamos valores de enumeraciones a las que
hemos aplicado el atributo Flags y a las que no se lo hemos aplicado. Empecemos por
este último caso.
Rojo = 1
Verde = 2
Azul = 4
End Enum
Pero si ese mismo código lo usamos de esta forma (aplicando el atributo Flags a la
enumeración):
<Flags()> _
Rojo = 1
Verde = 2
Azul = 4
End Enum
Los miembros de las enumeraciones realmente son valores de un tipo de datos entero
(en cualquiera de sus variedades) tal como podemos comprobar en la Figura 2.7:
Por tanto cabe pensar que podemos usar cualquier valor para asignar a una variable
declarada como una enumeración, al menos si ese valor está dentro del rango
adecuado. Es decir, en el ejemplo de la figura usar un 1 en lugar de Colores.Rojo.
El error nos indica que no podemos realizar esa asignación, pero el entorno integrado
de Visual Studio 2005 también nos ofrece alternativas para que ese error no se
produzca, esa ayuda se obtiene presionando el signo de admiración que tenemos
justo donde está el cursor del mouse, pero no solo nos dice cómo corregirlo, sino que
también nos da la posibilidad de que el propio IDE se encargue de hacerlo, tal como
podemos apreciar en la Figura 2.9.
CType es una de las formas que nos ofrece Visual Basic 2005 de hacer conversiones
entre diferentes tipos de datos, en este caso convertimos un valor entero en uno del
tipo enumerado Colores.
Es posible que usando CType no asignemos un valor dentro del rango permitido. En
este caso, el valor 3 podríamos darlo por bueno, ya que es la suma de 1 y 2 (Rojo y
Verde), pero ¿qué pasaría si el valor asignado es, por ejemplo, 15? En teoría no
deberíamos permitirlo.
1- Con la clásica solución de comprobar el valor indicado con todos los valores
posibles.
2- Usando funciones específicas del tipo Enum. Aunque en este último caso, solo
podremos comprobar los valores definidos en la enumeración.
c = Colores.Azul
End If
End Sub
Este código lo que hace es comprobar si el tipo de datos Colores tiene definido el
valor contenido en la variable c, en caso de que no sea así, usamos un valor
predeterminado.
Nota:
La función IsDefined sólo comprueba los valores que se han definido en
la enumeración, no las posibles combinaciones que podemos conseguir
sumando cada uno de sus miembros, incluso aunque hayamos usado el
atributo FlagsAttribute.
Los arrays (o matrices) también es algo que podíamos usar en VBScript/VB6, si bien
la forma en que se almacena en la memoria y la forma en que podemos usarlas en
Visual Basic 2005 ha cambiado.
Otra posibilidad que teníamos en VBScript/VB6 era indicar el rango de índices que
podíamos asignar, esto lo lográbamos usando la cláusula To al definir un array, por
ejemplo:
Dim nombres(10 To 25) As String
Pero esta declaración es ilegal en Visual Basic 2005, por el hecho de que los arrays
de .NET siempre deben tener el valor cero como índice inferior.
Lo que si podemos hacer en Visual Basic 2005 es usar To para indicar el valor máximo
del índice, aunque no tiene la misma "potencia" que en VBScript/VB6, al menos de
esta forma el código resultará más legible:
Con el código anterior estamos creando un array de tipo String con tres valores cuyos
índices van de cero a dos.
nombres(0,0)= Juan
nombres(0,1)= Pepe
nombres(1,0)= Ana
nombres(1,1)= Eva
Una vez que hemos declarado un array y le hemos asignado valores, es posible que
nos interese eliminar esos valores de la memoria, para lograrlo, podemos hacerlo de
tres formas:
Como acabamos de ver, en Visual Basic 2005 los arrays son tipos por referencia, y tal
como comentamos anteriormente, los tipos por referencia realmente lo que contienen
son una referencia a los datos reales no los datos propiamente dichos.
¿Cual es el problema?
otros = nombres
nombres(0) = "Antonio"
Que debido a que los arrays son tipos por referencia, solamente existe una copia de
los datos y tanto la variable nombres como la variable otros lo que contienen es una
referencia (o puntero) a los datos.
Si realmente queremos tener copias independientes, debemos hacer una copia del
array nombres en el array otros, esto es fácil de hacer si usamos el método CopyTo.
Éste método existe en todos los arrays y nos permite copiar un array en otro
empezando por el índice que indiquemos. El único requisito es que el array de
destino debe estar inicializado y tener espacio suficiente para contener los elementos
que queremos copiar.
En el siguiente código de ejemplo hacemos una copia del contenido del array
nombres en el array otros, de esta forma, el cambio realizado en el elemento cero
de nombres no afecta al del array otros.
ReDim otros(nombres.Length)
nombres.CopyTo(otros, 0)
nombres(0) = "Antonio"
Además del método CopyTo, los arrays tienen otros miembros que nos pueden ser de
utilidad, como por ejemplo la propiedad Length usada en el ejemplo para saber
cuantos elementos tiene el array nombres.
Para finalizar este tema, solo nos queda por decir, que los arrays de Visual Basic 2005
realmente son tipos de datos derivados de la clase Array y por tanto disponen de
todos los miembros definidos en esa clase, aunque de esto hablaremos en la próxima
lección, en la que también tendremos la oportunidad de profundizar un poco más en
los tipos por referencia y en como podemos definir nuestros propios tipos de datos,
tanto por referencia como por valor.
Ver video 1 de esta lección (Agregar proyectos a una solución, Arrays)
Ver video 2 de esta lección (Arrays 2)
Ver video 3 de esta lección (Arrays 3)
Introducción
También tendremos ocasión de ver los distintos niveles de accesibilidad que podemos
aplicar a los tipos, así como a los distintos miembros de esos tipos de datos. De los
distintos miembros que podemos definir en nuestros tipos, nos centraremos en las
propiedades para ver en detalle los cambios que han sufrido con respecto a las clases
de VBScript/VB6. También veremos temas relacionados con la programación
orientada a objetos (POO) en general y de forma particular los que atañen a las
interfaces.
Clases y estructuras
· Accesibilidad y ámbito
o Ámbito
§ Ámbito de bloque
§ Ámbito de procedimiento
§ Ámbito de módulo
§ Ámbito de espacio de nombres
o La palabra clave Global
o Accesibilidad
§ Accesibilidad de las variables en los procedimientos
o Las accesibilidades predeterminadas
o Anidado de tipos
§ Los tipos anidables
§ El nombre completo de un tipo
§ Importación de espacios de nombres
§ Alias de espacios de nombres
· Propiedades
o Definir una propiedad
o Propiedades de solo lectura
o Propiedades de solo escritura
o Diferente accesibilidad para los bloques Get y Set
o Propiedades predeterminadas
§ Sobrecarga de propiedades predeterminadas
· Interfaces
o ¿Qué es una interfaz?
o ¿Qué contiene una interfaz?
o Una interfaz es un contrato
o Las interfaces y el polimorfismo
o Usar una interfaz en una clase
o Acceder a los miembros implementados
o Saber si un objeto implementa una interfaz
o Implementación de múltiples interfaces
o Múltiple implementación de un mismo miembro
o ¿Dónde podemos implementar las interfaces?
o Un ejemplo práctico usando una interfaz de .NET
Clases: Tipos por referencia definidos por el usuario
Tal como vimos en la lección anterior, los tipos de datos se dividen en dos grupos:
tipos por valor y tipos por referencia. Los tipos por referencia realmente son clases,
de la cuales debemos crear una instancia para poder usarlas. Esa instancia o copia, se
crea siempre en la memoria lejana (heap) y las variables lo único que contienen es
una referencia a la dirección de memoria en la que el CLR (Common Language
Runtime, motor en tiempo de ejecución de .NET), ha almacenado el objeto recién
creado.
Al igual que ocurre en VBScript/VB6, también podemos crear nuestras propias clases
en Visual Basic 2005, aunque como veremos tanto la forma de definirlas como de
instanciarlas ha cambiado un poco. Aunque ese cambio es solo, digamos, en la forma,
ya que en el fondo es lo mismo, siempre salvando las distancias, ya que como
veremos, las clases de Visual Basic 2005 pueden llegar a ser mucho más versátiles y
potentes que las de VBScript/VB6.
Antes de entrar en detalles sintácticos, veamos la importancia que tienen las clases
en .NET Framework y como repercuten en las que podamos definir nosotros usando
Visual Basic 2005.
El tipo de herencia que .NET Framework soporta es la herencia simple, es decir, solo
podemos usar una clase como base de la nueva, si bien, como veremos más adelante,
podemos agregar múltiples interfaces. La herencia nos permitirá aprovechar la
funcionalidad de muchas de las clases existentes en la plataforma .NET.
La encapsulación nos permite abstraer la forma que tiene de actuar una clase sobre
los datos que contiene o manipula, para poder lograrlo se exponen como parte de la
clase los métodos y propiedades necesarios para que podamos manejar esos datos
sin tener que preocuparnos cómo se realiza dicha manipulación.
El ejemplo clásico del polimorfismo es que si tengo un objeto que "sabe" cómo
morder, da igual que lo aplique a un ratón o a un dinosaurio, siempre y cuando esas
dos "clases" expongan un método que pueda realizar esa acción... y como decía la
documentación de Visual Basic 5.0, siempre será preferible que nos muerda un ratón
antes que un dinosaurio.
Todas las clases de .NET se derivan siempre de forma automática de la clase Object,
lo indiquemos o no explícitamente. Cualquier clase que definamos tendrá el
comportamiento heredado de esa clase. El uso de la clase Object como base del resto
de las clases de .NET es la única excepción a la herencia simple soportada por .NET.
Esta característica nos asegura que siempre podremos usar un objeto del tipo Object
para acceder a cualquier clase de .NET, de manera similar a como un variant servía
en VBScript/VB6 para tratar cualquier tipo de objeto.
De los miembros que tiene la clase Object debemos resaltar el método ToString, el
cual ya lo vimos en la lección anterior cuando queríamos convertir un tipo primitivo en
una cadena. Este método está pensado para devolver una representación en formato
cadena de un objeto. El valor que obtengamos al usar este método dependerá de
cómo esté definido en cada clase y por defecto lo que devuelve es el nombre
completo de la clase. En la mayoría de los casos, sin embargo, el valor obtenido al
usar este método debería ser más intuitivo: por ejemplo los tipos de datos primitivos
tienen definido este método para devuelva el valor que contienen. De igual forma,
nuestras clases también deberían devolver un valor adecuado al contenido
almacenado. De cómo hacerlo, nos ocuparemos en breve.
Nota:
Todos los tipos de datos de .NET, ya sean por valor o por referencia
siempre están derivados de la clase Object, por tanto podremos llamar a
cualquiera de los métodos que están definidos en esa clase.
Aunque en el caso de los tipos de datos por valor, cuando queremos
acceder a la clase Object que contienen, .NET Framework primero debe
convertirla en un objeto por referencia (operación denominada boxing) y
cuando hemos dejado de usarla y queremos volver a asignar el dato a la
variable por valor, tiene que volver a hacer la conversión inversa
(unboxing).
En Visual Basic 6.0, cada vez que definimos una clase tenemos que agregar al
proyecto un fichero con extensión .cls, y a partir de ese momento, todo el código
escrito en ese fichero formaba parte de la clase. En VBScript (tanto en ASP como en
otros entornos) y en Visual Basic 2005 esto se hace mediante el uso de la palabra
clave Class. Aunque lo habitual es que usemos un fichero independiente para cada
clase que escribamos, esto solo es algo opcional, porque en VB2005 solo existe un
tipo de fichero para escribir el código: un fichero con extensión .vb, en el que
podemos escribir una clase o cualquiera de los tipos que el lenguaje nos permite.
Nota:
En Visual Basic 2005 cualquier código que queramos escribir estará
dentro de una clase.
En Visual Basic 2005 las clases se definen usando la palabra clave Class seguida del
nombre de la clase, esa definición acaba indicándolo con End Class, exactamente igual
que en VBScript.
En el siguiente ejemplo definimos una clase llamada Cliente que tiene dos campos
públicos.
Class Cliente
End Class
Una vez definida la clase podemos agregar los elementos (o miembros) que creamos
conveniente. En el ejemplo, para simplificar, hemos agregado dos campos públicos,
aunque también podríamos haber definido cualquiera de los miembros permitidos en
las clases.
En Visual Basic 2005 también podemos definir una clase especial llamada Module.
Este tipo de clase tiene un tratamiento especial y es el equivalente a los módulos BAS
de VB6. La definición se hace usando la instrucción Module seguida del nombre a usar
y acaba con End Module.
· Enumeraciones
· Campos
· Métodos (funciones o procedimientos)
· Propiedades
· Eventos
Los campos son variables usadas para mantener los datos que la clase manipulará.
Los métodos son las acciones que la clase puede realizar, normalmente esas
acciones serán sobre los datos que contiene. Dependiendo de que el método devuelva
o no un valor, podemos usar métodos de tipo Function o de tipo Sub respectivamente.
Los eventos son mensajes que la clase puede enviar para informar que algo está
ocurriendo en la clase.
Características de los métodos y propiedades
Aunque estos temas los veremos en breve con más detalle, para poder comprender
mejor las características de los miembros de una clase o tipo, daremos un pequeño
adelanto sobre estas características que podemos aplicar a los elementos que
definamos.
Si bien cada uno de ellos tienen su propia "semántica", tal como podemos ver a
continuación:
Ámbito
Es el alcance que la definición de un miembro o tipo puede tener. Es decir, cómo
podemos acceder a ese elemento y desde dónde podemos accederlo.
El ámbito de un elemento de código está restringido por el "sitio" en el que lo hemos
declarado. Estos sitios pueden ser:
Accesibilidad
A los distintos elementos de nuestro código (ya sean clases o miembros de las clases)
podemos darle diferentes tipos de accesibilidad. Estos tipos de "acceso" dependerán
del ámbito que queramos que tengan, es decir, desde dónde podremos accederlos.
Los modificadores de accesibilidad son:
Nota:
Al igual que ocurre en VBScript/VB6, al declarar una variable con Dim,
por regla general, el ámbito que le estamos aplicando es privado, pero
como veremos, en Visual Basic 2005, dependiendo del tipo en el que
declaremos esa variable, el ámbito puede ser diferente a privado.
Miembros compartidos
Por otro lado, los miembros compartidos de una clase o tipo, son elementos que no
pertenecen a una instancia o copia en memoria particular, sino que pertenecen al
propio tipo y por tanto siempre están accesibles o disponibles, dentro del nivel del
ámbito y accesibilidad que les hayamos aplicado, y su tiempo de vida es el mismo que
el de la aplicación.
Nota:
Lo más parecido en VB6 a los miembros compartidos de Visual Basic
2005 son los métodos y campos declarados en un módulo .BAS.
Del ámbito, la accesibilidad y los miembros compartidos nos ocuparemos con más
detalle en una lección posterior, donde veremos ciertas peculiaridades, como puede
ser la limitación del ámbito de un miembro que aparentemente tiene una accesibilidad
no restringida.
En Visual Basic 2005, tanto los miembros de una clase, (funciones y métodos Sub),
como las propiedades pueden recibir parámetros. Esto no es algo nuevo, ya que en
VB6 podíamos tener parámetros en estos tipos de miembros (o elementos) de una
clase, además se siguen soportando tanto los parámetros opcionales (Optional) como
los arrays de parámetros (ParamArray). Con los parámetros opcionales lo que
conseguimos es permitir que el usuario no tenga que introducir todos los parámetros,
sino solo los que realmente necesite, del resto, (los no especificados), se usará el
valor predeterminado que hayamos indicado, ya que una de las "restricciones" de este
tipo de parámetros con respecto a VBScript/VB6 es que siempre que indiquemos un
parámetro opcional, debemos indicar también el valor por defecto que debemos usar
en caso de que no se especifique. Esto realmente sigue funcionando igual que en VB6
cuando al parámetro opcional le indicamos el tipo de datos. Lo que Visual Basic 2005
no permite es definir un parámetro opcional de tipo Variant, entre otras cosas, porque
ese tipo de datos no existe en VB2005.
Suma = n1 + n2
End Function
t = Suma(1, 3)
t = Suma(1)
t = Suma(1, n2:= 9)
Nota:
Los parámetros opcionales deben aparecer en la lista de parámetros del
método, después de los "obligatorios"
En cuanto al uso de ParamArray, este tipo de parámetro opcional nos permite indicar
un número indeterminado de parámetros, aunque el funcionamiento con respecto a
VBScript/VB6 es algo diferente, en Visual Basic 2005 siempre debe ser una array de
un tipo específico e internamente se trata como un array normal y corriente, es decir,
dentro del método o propiedad se accede a él como si de un array se tratara... entre
otras cosas, ¡porque es un array!
En VB6 no siempre era así y algunas veces teníamos verdaderos problemas al acceder
a esos datos, por suerte, en Visual Basic 2005 el uso de los parámetros opcionales
con ParamArray es más simple e intuitivo, aunque a algunos puede que le parezca
menos "potente", ya que en VBScript/VB6, cualquiera de los parámetros podía ser a
su vez un array. Pero en Visual Basic 2005, al menos si tenemos activado Option
Strict, esto no es posible, ya que solo aceptará los parámetros del tipo indicado.
Dim i As Long
Dim j As Long
'
For i = 0 To UBound(n)
If IsArray(n(i)) Then
Next
Else
End If
Next
Suma = total
End Function
Dim t As Long
t = Suma(a, 4, 5, 6)
MsgBox(t)
Para usar este código en Visual Basic 2005 tendremos que desactivar Option Strict y
cambiar el tipo Variant por Object, (cosa que el IDE hará automáticamente si
pegamos el código), lo demás se puede quedar igual, incluso los tipos de datos,
aunque debemos recordar que un Long de VBScript/VB6 es un Integer de VB2005.
Pero como no debemos "acostumbrarnos" a desactivar Option Strict, vamos a ver el
código "bueno" de Visual Basic 2005, aunque no nos permita usar un array en los
parámetros al llamar a la función.
total += CInt(n(i))
Next
Return total
End Function
'
MsgBox(t)
Nota:
Cuando queramos usar ParamArray para recibir un array de parámetros
opcionales, esta instrucción debe ser la última de la lista de parámetros
de la función (método).
Supongamos que queremos tener dos funciones (o más) que nos permitan hacer
operaciones con diferentes tipos de datos, y que, según el tipo de datos usado, el
valor que devuelva sea de ese mismo tipo. En VB6 es imposible hacer esto. Salvo que
creemos dos funciones con nombres diferentes, pero en ese caso ya no estaremos
usando la sobrecarga.
En este ejemplo, tenemos dos funciones que se llaman igual pero una recibe valores
de tipo entero y la otra de tipo decimal:
Return n1 + n2
End Function
Return n1 + n2
End Function
Como podemos comprobar las dos funciones tienen el mismo nombre, pero tanto una
como otra reciben parámetros de tipos diferentes.
Con Visual Basic 2005 podemos sobrecargar funciones, pero lo interesante no es que
podamos hacerlo, sino cómo podemos usar esas funciones. En el código anterior
tenemos dos funciones llamadas Suma, la primera acepta dos parámetros de tipo
Integer y la segunda de tipo Double. Lo interesante es que cuando queramos usarlas,
no tenemos que preocuparnos de cual vamos a usar, ya que será el compilador el que
decida la más adecuada al código que usemos, por ejemplo:
Return n1 + n2 + n3
End Function
Por tanto, cuando el compilador se encuentre con una llamada a la función Suma en
la que se usen tres parámetros, intentará usar esta última.
Nota:
Para que exista sobrecarga, la diferencia debe estar en el número o en el
tipo de los parámetros, no en el tipo del valor devuelto.
Cuando, desde el IDE de Visual Studio 2005, queremos usar los métodos
sobrecargados, nos mostrará una lista de opciones indicándonos las posibilidades de
sobrecarga que existen y entre las que podemos elegir, tal como vemos en la Figura
2.10:
Tal como comentábamos hace unas líneas, en VB6 se puede simular la sobrecarga
mediante los parámetros opcionales, aunque realmente no es lo mismo. Pero esa
"simulación" nos viene como anillo al dedo para dar un consejo o advertencia:
¡Cuidado con las funciones que reciben parámetros opcionales, ya que el
compilador puede producir un error si esa función entra en conflicto con otra
"sobrecargada"!
End Function
Al igual que tenemos dos tipos de datos diferentes, en los parámetros de las
funciones también podemos tenerlos, esto tampoco es una novedad de Visual Basic
2005, ya que en VBScript/VB6 también podemos usar ByVal o ByRef para indicar al
compilador cómo debe tratar a los parámetros.
En el caso de que el parámetro sea por referencia (ByRef), el compilador pasa una
referencia que apunta a la dirección de memoria en la que están los datos, por tanto
si realizamos cambios dentro de la función, ese cambio si que se verá reflejado en el
parámetro usado al llamar a la función.
Nota:
Hay que tener en cuenta que si pasamos un objeto a una función, da
igual que lo declaremos por valor o por referencia, ya que en ambos
casos se pasa una referencia a la dirección de memoria en la que están
los datos, porque, como sabemos, las variables de los tipos por
referencia siempre contienen una referencia a los datos, no los datos en
sí.
Lo que cambia en Visual Basic 2005 es que ahora los parámetros en los que no se
indique si es por valor (ByVal) o por referencia (ByRef), serán tratados como
parámetros por valor. En VBScript/VB6 era al revés.
Nota:
Si usamos el IDE de Visual Studio para escribir el código, no debemos
preocuparnos de este detalle, ya que si no indicamos si es por valor o
por referencia, automáticamente le añadirá la palabra clave ByVal, para
que no haya ningún tipo de dudas.
Ver video 1 de esta lección (Clases 2: Los miembros de las clases)
Ver video 2 de esta lección (Clases 3: Las propiedades)
Ver video 3 de esta lección (Clases 4: Accesibilidad)
Instanciar: Crear un objeto en la memoria
Una vez que tenemos una clase definida, lo único de lo que disponemos es de una
especie de plantilla o molde a partir del cual podemos crear objetos en memoria.
La forma de crear esos objetos en Visual Basic 2005 no ha cambiado con respecto al
VBScript/VB6, salvo en pequeños detalles, veamos algunos ejemplos y así
aclararemos esas diferencias, que por otro lado son importantes.
Lo primero que tenemos que hacer es declarar una variable del tipo que queremos
instanciar, esto lo hacemos usando la instrucción Dim:
Dim c As Cliente
Con esta línea de código lo que estamos indicando al Visual Basic es que tenemos
intención de usar una variable llamada c para acceder a una clase de tipo Cliente.
Esa variable, cuando llegue el momento de usarla, sabrá todo lo que hay que saber
sobre una clase Cliente, pero hasta que no tenga una "referencia" a un objeto de ese
tipo no podremos usarla.
La asignación de una referencia a un objeto Cliente podemos hacerla de dos formas
distintas:
La primera es creando un nuevo objeto en la memoria:
c = New Cliente
Nota:
En VBScript/VB6 esta forma de crear un nuevo objeto produciría un
error, ya que para "asignar" a una variable un nuevo objeto tenemos
que usar la instrucción Set, en Visual Basic 2005 ya no es necesario el
uso de esa instrucción, de hecho si la usamos, recibiremos un error.
A partir de este momento, la variable c tiene acceso a un nuevo objeto del tipo
Cliente, por tanto podremos usarla para asignarle valores y usar cualquiera de los
miembros que ese tipo de datos contenga:
c.Nombre = "Antonio"
Con las clases o tipos por referencia también podemos declarar una variable y al
mismo tiempo asignarle un nuevo objeto, esto tampoco es una novedad, aunque sí lo
es la forma de comportarse. Veamos primero cómo hacerlo y después entraremos en
detalles.
O también:
Las dos formas producen el mismo resultado, por tanto es recomendable usar la
primera.
Lo que debemos tener muy presente es que además de la sobrecarga de trabajo que
añade VBScript/VB6 a este tipo de instanciación, el comportamiento es muy diferente
al de Visual Basic 2005. Por ejemplo, si en VBScript/VB6 asignamos un valor nulo
(Nothing) a una variable declarada de esta forma y acto seguido usamos la variable,
el motor en tiempo de ejecución (runtime) crea un nuevo objeto y asunto arreglado.
Pero en Visual Basic 2005, si asignamos un valor nulo a una variable, le estamos
diciendo al CLR (el runtime de .NET) que ya no queremos usar más ese objeto, por
tanto lo elimina de la memoria; si después queremos volver a usar la variable,
debemos crear otro objeto, (con New), de no hacerlo, se producirá un error, ya que
en Visual Basic 2005 no existe la auto-instanciación.
Cada vez que creamos un nuevo objeto en memoria estamos llamando al constructor
de la clase. En VBScript/VB6 el constructor es el método Class_Initialize. Sin embargo
en Visual Basic 2005 el constructor es un método de tipo Sub llamado New.
Si nuestra clase Cliente tiene un campo para almacenar la fecha de creación del
objeto podemos hacer algo como esto:
Class Cliente
'
FechaCreacion = Date.Now
End Sub
End Class
De esta forma podemos crear un nuevo Cliente y acto seguido comprobar el valor del
campo FechaCreacion para saber la fecha de creación del objeto.
En los constructores también podemos hacer las inicializaciones que, por ejemplo
permitan a la clase a conectarse con una base de datos, abrir un fichero o cargar una
imagen gráfica, etc., aunque en algunos de estos casos nos facilitará la tarea una
nueva característica que VBScript/VB6 no tiene.
Constructores parametrizados
Para comprobarlo, podemos ampliar la clase definida anteriormente para que también
acepte la creación de nuevos objetos indicando el nombre y los apellidos del cliente.
Class Cliente
'
FechaCreacion = Date.Now
End Sub
'
Nombre = elNombre
Apellidos = losApellidos
FechaCreacion = Date.Now
End Sub
End Class
Teniendo esta declaración de la clase Cliente, podemos crear nuevos clientes de dos
formas:
Class Cliente
'
FechaCreacion = Date.Now
End Sub
'
New()
Nombre = elNombre
Apellidos = losApellidos
End Sub
End Class
Pero hay ocasiones en las que nos puede interesar que no exista un constructor sin
parámetros, por ejemplo, podemos crear una clase Cliente que solo se pueda
instanciar si le pasamos, por ejemplo el número de identificación fiscal, (NIF), en caso
de que no se indique ese dato, no podremos crear un nuevo objeto Cliente, de esta
forma, nos aseguramos siempre de que el NIF siempre esté especificado.
Seguramente por ese motivo, si nosotros definimos un constructor con parámetros,
Visual Basic 2005 no crea uno automáticamente sin parámetros. Por tanto, si
definimos un constructor con parámetros en una clase y queremos que también tenga
uno sin parámetros, lo tenemos que definir nosotros mismos.
Debido a esta característica de .NET, si nuestra clase hace uso de recursos externos
que necesiten ser eliminados cuando la el objeto ya no se vaya a seguir usando,
debemos definir un método que sea el encargado de realizar esa liberación, pero ese
método debemos llamarlo de forma manual, ya que, aunque en .NET existen formas
de hacer que esa llamada sea automática, nunca tenderemos la seguridad de que se
llame en el momento oportuno, y esto es algo que, según que casos, puede ser un
inconveniente.
Recomendación:
Si nuestra clase utiliza recursos externos, por ejemplo un fichero o una
base de datos, debemos definir un método que se encargue de liberarlos
y a ese método debemos encargarnos de llamarlo cuando ya no lo
necesitemos.
Por definición a este tipo de métodos se les suele dar el nombre Close o
Dispose, aunque este último tiene un significado especial y por
convención solo debemos usarlo siguiendo las indicaciones de la
documentación.
De la misma forma que podemos definir nuestros propios tipos de datos por
referencia, Visual Basic 2005 nos permite crear nuestros propios tipos por valor.
Para crear nuestros tipos de datos por referencia, usamos la "instrucción" Class, por
tanto es de esperar que también exista una instrucción para crear nuestros tipos por
valor, y esa instrucción es: Structure, por eso en Visual Basic 2005 a los tipos por
valor definidos por el usuario se denominan estructuras.
Nota:
El equivalente en VB6 a una estructura de Visual Basic 2005 es Type (se
le solía denominar tipo definido por el usuario o UDT) aunque es solo
eso: un parecido, pero realmente no es equivalente, al menos al 100%,
tal como tendremos oportunidad de comprobar en esta lección.
Las estructuras pueden contener los mismos miembros que las clases, aunque
algunos de ellos se comporten de forma diferente o al menos tengan algunas
restricciones, como que los campos definidos en las estructuras no se pueden
inicializar al mismo tiempo que se declaran o no pueden contener constructores
"simples", ya que el propio compilador siempre se encarga de crearlo, para así poder
inicializar todos los campos definidos.
Las estructuras se definen usando la palabra Structure seguida del nombre y acaba
usando las instrucciones End Structure.
El siguiente código define una estructura llamada Punto en la que tenemos dos
campos públicos.
Structure Punto
Public X As Integer
Public Y As Integer
End Structure
Dim p As Punto
p.X = 100
p.Y = 75
Tal y como hemos comentado, las estructuras siempre definen un constructor sin
parámetros, este constructor no lo podemos definir nosotros, es decir, siempre existe
y es el que el propio compilador de Visual Basic 2005 define.
Por tanto, si queremos agregar algún constructor a una estructura, este debe tener
parámetros y, tal como ocurre con cualquier método o como ocurre en las clases,
podemos tener varias sobrecargas de constructores parametrizados en las
estructuras. La forma de definir esos constructores es como vimos en las clases:
usando distintas sobrecargas de un método llamado New, en el caso de las
estructuras también podemos usar la palabra clave Me para referirnos a la instancia
actual.
Public X As Integer
Public Y As Integer
'
Me.X = x
Me.Y = y
End Sub
End Structure
Nota:
Tanto en las estructuras como en las clases podemos tener
constructores compartidos, en el caso de las estructuras, este tipo de
constructor es el único que podemos declarar sin parámetros.
Debido a que las estructuras son tipos por valor y por tanto una variable declarada
con un tipo por valor "contiene el valor en si misma", no podemos destruir este tipo
de datos, lo más que conseguiríamos al asignarle un valor nulo (Nothing) sería
eliminar el contenido de la variable, pero nunca podemos destruir ese valor. Por
tanto, en las estructuras no podemos definir destructores.
Como hemos comentado, los miembros o elementos que podemos definir en una
estructura son los mismos que ya vimos en las clases. Por tanto aquí veremos las
diferencias que existen al usarlos en las estructuras.
Campos
Como vimos, las variables declaradas a nivel del tipo, son los campos. La principal
diferencia con respecto a las clases, es que los campos de una estructura no pueden
inicialiarse en la declaración y el valor que tendrán inicialmente es un valor "nulo",
que en el caso de los campos de tipo numéricos es un cero.
Por tanto, si necesitamos que los campos tengan algún valor inicial antes de usarlos,
deberíamos indicarlo a los usuarios de nuestra estructura y proveer un constructor
que realice las inicializaciones correspondientes, pero debemos recordar que ese
constructor debe tener algún parámetro, ya que el predeterminado sin parámetros no
podemos "reescribirlo".
Los únicos campos que podemos inicializar al declararlos son los campos compartidos,
pero como tendremos oportunidad de ver, estos campos serán accesibles por
cualquier variable declarada y cualquier cambio que realicemos en ellos se verá
reflejado en el resto de "instancias" de nuestro tipo.
Otro detalle a tener en cuenta es que en una estructura siempre debe existir al menos
un evento o un campo no compartido, no se permiten estructuras en las que solo
tienen constantes, métodos y/o propiedades, estén o no compartidos.
Tal como hemos comentado las estructuras son tipos por valor, para usar los tipos por
valor no es necesario instanciarlos explícitamente, ya que el mero hecho de
declararlos indica que estamos creando un nuevo objeto en memoria. Por tanto, a
diferencia de las clases o tipos por referencia, cada variable definida como un tipo de
estructura será independiente de otras variables declaradas, aunque no las hayamos
instanciado.
Esta característica de las estructuras nos permite hacer copias "reales" no copia de la
referencia (o puntero) al objeto en memoria como ocurre con los tipos por referencia.
Veámoslos con un ejemplo.
Dim p1 As Punto
p1 = p
p1.X = 200
En este trozo de código definimos e instanciamos una variable del tipo Punto, a
continuación declaramos otra variable del mismo tipo y le asignamos la primera, si
estos tipos fuesen por referencia, tanto una como la otra estarían haciendo referencia
al mismo objeto en memoria, y cualquier cambio realizado a cualquiera de las dos
variables afectarían al mismo objeto, pero en el caso de las estructuras (y de los tipos
por valor), cada cambio que realicemos se hará sobre un objeto diferente, por tanto la
asignación del valor 200 al campo X de la variable p1 solo afecta a esa variable,
dejando intacto el valor original de la variable p.
Ver video de esta lección (Estructuras)
Accesibilidad y ámbito
Ámbito
Nota:
Por regla general, cuando declaramos una variable en un ámbito, dicha
variable "ocultará" a otra que tenga el mismo nombre y esté definida en
un bloque con mayor alcance, aunque veremos que en Visual Basic 2005
existen ciertas restricciones dependiendo de dónde declaremos esas
variables.
En Visual Basic 2005 podemos definir una variable dentro de un bloque de código, en
ese caso dicha variable solo será accesible dentro de ese bloque. Aunque, como
veremos a continuación, en un procedimiento solamente podremos definir variables
que no se oculten entre sí, estén o no dentro de un bloque de código.
Ámbito de bloque
En los siguientes ejemplos veremos cómo podemos definir variables para usar
solamente en el bloque en el que están definidas.
Los bloques de código en los que podemos declarar variables son los bucles, (For, Do,
While), y los bloques condicionales, (If, Select).
Por ejemplo, dentro de un procedimiento podemos tener varios de estos bloques y por
tanto podemos definir variables "internas" a esos bloques:
Dim n As Integer = 3
'
For i As Integer = 1 To 10
Dim j As Integer
j += 1
If j < n Then
'...
End If
Next
'
If n < 5 Then
Dim j As Integer = n * 3
End If
'
Do
Dim j As Integer
For i As Integer = 1 To n
j += i
Next
Loop
Ámbito de procedimiento
Las variables declaradas en un procedimiento tendrán un ámbito o cobertura que será
el procedimiento en el que está declaradas, y como hemos visto, ese ámbito incluye
también cualquier bloque de código declarado dentro del procedimiento.
Estas variables ocultarán a las que se hayan declarado fuera del procedimiento, si
bien, dependiendo del tipo de módulo, podremos acceder a esas variables "externas"
indicando el nombre completo del módulo o bien usando la instrucción Me, tal como
vimos en el código del constructor parametrizado de la estructura Punto.
Pero mejor veámoslo con un ejemplo. En el siguiente código, definimos una clase en
la que tenemos un campo llamado Nombre, también definimos un método en el que
internamente se utiliza una variable llamada nombre, para acceder a la variable
declarada en la clase, tendremos que usar la instrucción o palabra clave Me.
Return "Externo= " & Me.Nombre & ", interno= " & nombre
End Function
End Class
En este ejemplo, el hecho de que una variable esté declarada con la letra ene en
mayúscula o en minúscula no implica ninguna diferencia, ya que Visual Basic 2005 al
igual que VBScript/VB6 no hace distinciones de este tipo, si bien, en Visual Basic 2005
no se cambia automáticamente las mayúsculas y minúsculas de las variables, salvo
cuando están en el mismo nivel de ámbito; en cambio, si en VBScript/VB6 declaramos
una variable con el mismo nombre, aunque esté en un ámbito diferente, siempre se
usará el estado de mayúsculas/minúsculas de la última definición.
Ámbito de módulo
Cuando hablamos de módulos, nos estamos refiriendo a una clase, a una estructura o
a cualquier otro tipo de datos que nos permita .NET.
En estos casos, las variables declaradas dentro de un tipo de datos serán visibles
desde cualquier parte de ese tipo, siempre teniendo en cuenta las restricciones
mencionadas en los casos anteriores.
Ámbito de espacio de nombres
Los espacios de nombres son los contenedores de tipos de datos de mayor nivel, y
sirven para contener definiciones de clases, estructuras, enumeraciones y delegados
como ya comentamos en el primer módulo. Cualquier tipo definido en el ámbito del
espacio de nombres estará disponible para cualquier otro elemento definido en el
mismo espacio de nombres.
En Visual Basic 2005 podemos definir espacios de nombres cuyos nombres sean los
mismos que los definidos en el propio .NET Framework, para evitar conflictos de
ámbitos, podemos usar la palabra clave Global para acceder a los que se han definido
de forma "global" en .NET.
Por ejemplo, si tenemos el siguiente código en el que definimos una clase dentro de
un espacio de nombres llamado System y queremos acceder a uno de los tipos
definidos en el espacio de nombres System de .NET, tendremos un problema:
Namespace System
Class Cliente
End Class
End Namespace
El problema es que el compilador de Visual Basic 2005 nos indicará que el tipo Int32
no está definido, ya que intentará buscarlo dentro del ámbito que actualmente tiene,
es decir, la declaración que nosotros hemos hecho de System, por tanto para poder
acceder al tipo Int32 definido en el espacio de nombres "global" System de .NET
tendremos que usar la instrucción Global, por suerte el IDE de Visual Studio 2005
reconoce este tipo de error y nos ofrece ayuda para poder solventar el conflicto, tal
como vemos en la Figura 2.13:
Figura 2.13. Ayuda del IDE en los conflictos de espacios nombres globales
Nota:
Afortunadamente este conflicto con los espacios de nombres no será
muy habitual para los desarrolladores que usemos el idioma de
Cervantes, por la sencilla razón de que los espacios de nombres de .NET
Framework suelen estar definidos usando palabras en inglés.
Accesibilidad
Nota:
La palabra clave Static, tiene el mismo significado que en VB6, y nos
permite definir una variable privada (o local) al procedimiento para que
mantenga el valor entre diferentes llamadas a ese procedimiento; esto
contrasta con el resto de variables declaradas en un procedimiento cuya
duración es la misma que la vida del propio procedimiento, por tanto, las
variables no estáticas pierden el valor al terminar la ejecución del
procedimiento.
Por ejemplo, en las estructuras si definimos los campos usando Dim, estos tendrán un
ámbito igual que si le hubiésemos aplicado el modificador Public; sin embargo, esa
misma variable declarada en una clase (Class o Module) tendrá una accesibilidad
Private. Así mismo, si el elemento que declaramos es un procedimiento y no
indicamos el modificador de ámbito, éste tendrá un ámbito de tipo Public si lo
definimos en una estructura y si el lugar en el que lo declaramos es una clase (o
Module), éste será Friend.
Tal como podemos ver en la tabla 1.3, la accesibilidad predeterminada, (la que tienen
cuando no se indica expresamente con un modificador), de todos los tipos es Friend,
es decir, accesible a todo el proyecto, aunque en el caso de las enumeraciones el
modificador depende de dónde se declare dicha enumeración, si está declarada a nivel
de espacio de nombres será Friend, en el resto de los casos será Public.
En la tercera columna tenemos la accesibilidad predeterminada cuando declaramos
las variables con Dim, aunque en las interfaces y en las enumeraciones no se
permiten declarar variables.
La última columna es la correspondiente a los procedimientos, en el caso de las
interfaces no se puede aplicar ningún modificador de accesibilidad y de forma
predeterminada son públicos.
En esta otra tabla tenemos la accesibilidad permitida en cada tipo así como las que
podemos indicar en los miembros de esos tipos.
Algunos de los modificadores que podemos indicar en los tipos dependen de dónde
declaremos esos tipos, por ejemplo, tan solo podremos indicar el modificador privado
de las enumeraciones cuando estas se declaren dentro de un tipo. En el caso de las
clases e interfaces, los modificadores Protected y Protected Friend solo podremos
aplicarlos cuando están declaradas dentro de una clase (Class).
Anidado de tipos
Tal como hemos comentado en el párrafo anterior, podemos declarar tipos dentro de
otros tipos, por tanto el ámbito y accesibilidad de esos tipos dependen del ámbito y
accesibilidad del tipo que los contiene. Por ejemplo, si declaramos una clase con
acceso Friend, cualquier tipo que esta clase contenga siempre estará supeditado al
ámbito de esa clase, por tanto si declaramos otro tipo interno, aunque lo declaremos
como Public, nunca estará más accesible que la clase contenedora, aunque en estos
casos no habrá ningún tipo de confusión, ya que para acceder a los tipos declarados
dentro de otros tipos siempre tendremos que indicar la clase que los contiene.
En el siguiente código podemos ver cómo declarar dos clases "anidadas". Tal como
podemos comprobar, para acceder a la clase Salario debemos indicar la clase Cliente,
ya que la única forma de acceder a una clase anidada es mediante la clase
contenedora.
End Class
End Class
s.Importe = 2200
Nota:
Los espacios de nombres también pueden anidarse y contener a su vez
cualquiera de los tipos mostrados en la tabla 1.4, incluso tipos Module.
El nombre completo de un tipo
Tal como hemos visto, al poder declarar tipos dentro de otros tipos y estos a su vez
pueden estar definidos en espacios de nombres, podemos decir que el nombre
"completo" de un tipo cualquiera estará formado por el/los espacios de nombres y
el/los tipos que los contiene, por ejemplo si la clase Cliente definida anteriormente
está a su vez dentro del espacio de nombres Ambitos, el nombre completo será:
Ambitos.Cliente y el nombre completo de la clase Salario será:
Ambitos.Cliente.Salario.
Aunque para acceder a la clase Cliente no es necesario indicar el espacio de
nombres, al menos si la queremos usar desde cualquier otro tipo declarado dentro de
ese espacio de nombres, pero si nuestra intención es usarla desde otro espacio de
nombre externo a Ambitos, en ese caso si que tendremos que usar el nombre
completo.
Por ejemplo, en el siguiente código tenemos dos espacios de nombres que no están
anidados, cada uno de ellos declara una clase y desde una de ellas queremos acceder
a la otra clase, para poder hacerlo debemos indicar el nombre completo, ya que en
caso contrario, el compilador de Visual Basic 2005 sería incapaz de saber a que clase
queremos acceder.
Namespace Uno
End Class
End Namespace
Namespace Dos
Sub Main()
c1.Nombre = "Pepe"
End Sub
End Class
End Namespace
Esto mismo lo podemos aplicar en el caso de que tengamos dos clases con el mismo
nombre en espacios de nombres distintos.
Nota:
En el mismo proyecto podemos tener más de una declaración de un
espacio de nombres con el mismo nombre, en estos casos el compilador
lo tomará como si todas las clases definidas estuvieran dentro del mismo
espacio de nombres, aunque estos estén definidos en ficheros diferentes.
Para evitar estar escribiendo todos los espacios de nombres en los que está la clase
que nos interesa declarar, podemos usar una especie de acceso directo o para que lo
entendamos mejor, podemos crear una especie de "Path", de forma que al declarar
una variable, si esta no está definida en el espacio de nombres actual, el compilador
busque en todos los espacios de nombres incluidos en esas rutas (paths).
Imports Uno
Imports vb = Microsoft.VisualBasic
De esta forma podemos usar el "alias" vb para acceder a las clases y demás tipos
definidos en ese espacio de nombres.
En las figuras 1.14 1.15 podemos ver las dos formas de acceder a las clases del
espacio de ese espacio de nombres, en el primer caso sin usar un alias y en el
segundo usando el alias vb.
Las propiedades son los miembros de los tipos que nos permiten acceder a los datos
que dicho tipo manipula. Normalmente una propiedad está relacionada con un campo,
de forma que el campo sea el que realmente contenga el valor y la propiedad
simplemente sea una especie de método a través del cual podemos acceder a ese
valor.
Debido a que el uso de las propiedades realmente nos permite acceder a los valores
de una clase (o tipo), se suelen confundir los campos con las propiedades. De hecho
en VBScript/VB6 si definimos una variable pública, ésta se convierte en una propiedad
de la clase. En Visual Basic 2005 casi ocurre lo mismo, pero realmente un campo (o
variable) público no es una propiedad, al menos en el sentido de que el propio .NET
Framework no lo interpreta como tal, aunque en la práctica nos puede parecer que es
así, ya que se utilizan de la misma forma. Pero no debemos dejarnos llevar por la
comodidad y si no queremos perder funcionalidad, debemos diferenciar en nuestro
código las propiedades de los campos.
Lo primero que debemos tener presente es que gracias a esta diferenciación que hace
.NET Framework, (realmente VBScript/VB6 también la hace), podemos poner en
práctica una de las características de la programación orientada a objetos: la
encapsulación, de forma, que la manipulación de los datos que una clase contiene
siempre se deben hacer de forma "interna" o privada a la clase, dejando a las
propiedades la posibilidad de que externamente se manipulen, de forma controlada,
esos datos. De esta forma tendremos mayor control sobre cómo se acceden o se
asignan los valores a esos datos, ya que al definir una propiedad, tal como hemos
comentado, realmente estamos definiendo un procedimiento con el cual podemos
controlar cómo se acceden a esos datos.
Este concepto no ha cambiado, al menos en el fondo, con respecto a como lo
hacemos con VBScript/VB6, ya que en estos lenguajes también podemos declarar
procedimientos del tipo propiedad, aunque la forma de hacerlo en Visual Basic 2005 si
que ha cambiado un poco, tal como tendremos ocasión de ver a continuación.
Debido a que una propiedad realmente nos permite acceder a un dato que la clase (o
estructura) manipula, siempre tendremos un campo relacionado con una propiedad.
El campo será el que contenga el valor y la propiedad será la que nos permita
manipular ese valor.
En Visual Basic 2005, las propiedades las declaramos usando la instrucción Property y
la definición de la misma termina con End Property, esto es prácticamente igual (o
casi) que en VBScript/VB6. La diferencia principal es que en VBScript/VB6 cuando
definimos una propiedad, debemos hacerlo en partes, por ejemplo, si queremos
definir cuando accedemos al valor, declaramos esa acción usando las instrucciones
Property Get y para definir la parte de la propiedad que asigna un nuevo valor, lo
hacemos mediante Property Let. En Visual Basic 2005 esas dos acciones, la de lectura
(GET) y asignación (LET), las debemos indicar en dos bloques dentro de la propia
declaración de la propiedad, el bloque que nos permite acceder al valor de la
propiedad estará indicado por la instrucción Get y acaba con End Get, por otra parte,
el bloque usado para asignar un valor a la propiedad se define mediante la instrucción
Set y acaba con End Set.
Nota:
En VBScript/VB6 realmente disponemos de tres bloques o partes en la
definición de una propiedad:
Property Get, que nos permite acceder al valor de la propiedad.
Propery Let, que nos permite asignar un valor a la propiedad.
Property Set, el cual lo usamos cuando la propiedad representa un
objeto y queremos asignar dicho objeto a la propiedad.
La diferencia entre Let y Set es que el primero se usará en valores de
tipos por valor y el segundo en tipos por referencia, aunque el
compilador de VBScript/VB6 realmente usará uno u otro según
asignemos el valor directamente a la propiedad o usemos la instrucción
Set para hacer esa asignación.
Return _nombre
End Get
_nombre = value
End Set
End Property
End Class
Como podemos comprobar tenemos dos bloques de código, el bloque Get que es el
que se usa cuando queremos acceder al valor de la propiedad, por tanto devolvemos
el valor del campo privado usado para almacenar ese dato. El bloque Set es el usado
cuando asignamos un valor a la propiedad, este bloque tiene definido un parámetro
(value) que representa al valor que queremos asignar a la propiedad.
Aunque en Visual Basic 2005 las definiciones para obtener o asignar el valor de la
propiedad se hacen en bloques definidos dentro de un procedimiento del tipo
Property, esta forma de definir las propiedades no se diferencia demasiado a como lo
hacemos en VBScript/VB6, y una vez que nos acostumbremos lo veremos como una
forma más "compacta" de hacerlo.
En ciertas ocasiones nos puede resultar interesante que una propiedad sea de solo
lectura, de forma que el valor que representa no pueda ser cambiado.
En VBScript/VB6 para definir una propiedad de solo lectura bastaba con definir solo la
parte Get de la propiedad., En Visual Basic 2005 también se hace de esa forma, pero
debemos indicar expresamente que esa es nuestra intención. Por tanto no solo
basta con definir solo el bloque Get, sino que debemos usar el modificador ReadOnly
para que el compilador de Visual Basic 2005 acepte la declaración:
Get
Return Date.Now
End Get
End Property
Propiedades de solo escritura
De igual forma, si queremos definir una propiedad que sea de solo escritura, solo
definiremos el bloque Set, pero al igual que ocurre con las propiedades de solo
lectura, debemos indicar expresamente que esa es nuestra intención, para ello
usaremos la palabra clave WriteOnly:
' ok
End If
End Set
End Property
Por ejemplo, el salario de un empleado podríamos declararlo para que desde cualquier
punto se pueda saber el importe, pero la asignación de dicho importe solo estará
accesible para los procedimientos definidos en la propia clase:
Get
Return _salario
End Get
_salario = value
End Set
End Property
End Class
Para hacer que el bloque Set sea privado, lo indicamos con el modificador de
accesibilidad Private, al no indicar ningún modificador en el bloque Get, éste será el
mismo que el de la propiedad.
Nota:
El nivel de accesibilidad de los bloques Get o Set debe ser igual o inferior
que el de la propiedad, por tanto si la propiedad la declaramos como
Private, no podemos definir como público los bloques Get o Set.
Propiedades predeterminadas
Una cosa que echamos en falta en Visual Basic 2005 son las propiedades
predeterminadas. Aunque existen no son exactamente igual que en VB6. En VB6
podemos definir como propiedad predeterminada cualquiera de las propiedades de la
clase, aunque la forma de hacerlo es bastante "rebuscada" y poco intuitiva. Al menos
podemos definir como predeterminada la que más nos interese.
En Visual Basic 2005 no podemos definir como predeterminada cualquier propiedad,
ya que debido a como se realizan las asignaciones de objetos en .NET (sin necesidad
de usar Set), siempre debemos indicar la propiedad a la que queremos asignar el
valor, porque en caso de que no se indique ninguna, el compilador interpretará que lo
que queremos asignar es un objeto y no un valor a una propiedad.
Para evitar conflictos o tener que usar alguna instrucción "extra" para que se sepa si
lo que queremos asignar es un valor o un objeto, en Visual Basic 2005 las
propiedades predeterminadas siempre deben ser parametrizadas, es decir, tener
como mínimo un parámetro.
Para indicar que una propiedad es la propiedad por defecto lo debemos hacer usando
la instrucción Default:
Get
' ...
End Get
End Property
Como vemos en este ejemplo, una propiedad por defecto puede ser de solo lectura y
también de solo escritura o de lectura/escritura.
Para usar esta propiedad, al ser la propiedad por defecto, no es necesario indicar el
nombre de la propiedad, aunque si así lo deseamos podemos indicarla, aunque en
este caso no tendría mucha utilidad el haberla definido como propiedad por defecto:
Get
' ...
End Get
End Property
Get
' ...
End Get
'
End Set
End Property
Incluso como vemos en este código una de las sobrecargas puede ser de solo lectura
y la otra de lectura/escritura. Lo que realmente importa es que el número o tipo de
parámetros de cada sobrecarga sea diferente.
Get
Case 0
Return Descripción
Case 1
Return PrecioVenta.ToString
Case 2
Return Existencias.ToString
Case Else
Return ""
End Select
End Get
End Property
End Class
For i As Integer = 0 To 2
Console.WriteLine( art(i) )
Next
Resumiendo:
Las propiedades predeterminadas en Visual Basic 2005 siempre deben tener un
parámetro, para que su uso se asemeje a un array, es decir, se use como indizador
de la clase. Por convención, cuando se usan como indizador, el nombre de la
propiedad predeterminada suele ser Item.
Las interfaces son una forma especial de una clase, aunque la diferencia principal con
las clases es que las interfaces no contienen código ejecutable, solo definen los
miembros.
Para entenderlo mejor, veamos las interfaces desde el punto de vista de Visual Basic
6.0.
En Visual Basic 6.0, cuando definimos una clase, realmente estamos haciendo dos
cosas:
1- Definiendo una interfaz con cada uno de los miembros que la clase contiene: métodos,
propiedades, eventos, etc.
2- Definiendo el código a utilizar por cada uno de esos miembros.
Desde ese punto de vista, podemos decir que una interfaz define cada uno de los
miembros de una clase, es decir, que tipo de método es, si los métodos tienen
parámetros, cuantos y de que tipos son, que propiedades o eventos define la clase,
etc.
Por tanto, podemos decir que la interfaz de una clase indica los miembros que dicha
clase expone, y como hemos indicado anteriormente, cuando en VB6 definimos una
clase, también estamos definiendo una interfaz, de hecho en Visual Basic 6.0 no hay
forma de definir interfaces como algo independiente de una clase; cuando queremos
definir una interfaz en VB6, lo más que podemos hacer es definir una clase sin código
ejecutable.
Pero Visual Basic 2005, va aún más lejos, ya que las interfaces las definimos de forma
independiente de las clases. Es más, cuando definimos una clase NO estamos
definiendo una interfaz.
Para definir una interfaz en VB2005 tenemos que usar la instrucción Interface seguida
del nombre y terminar la declaración con End Interface:
'...
End Interface
Nota:
Según las indicaciones de nomenclatura de .NET Framework, se
recomienda que todas las interfaces empiecen con una I mayúscula
seguida del nombre al que hacer referencia la interfaz.
Al principio de esta lección hemos comentado que las interfaces no contienen código,
solo define los miembros que contiene. Esa definición la haremos como cualquier otra,
con la diferencia de que no incluimos ningún código, solo la "firma" o el prototipo de
cada uno de esos miembros.
En el siguiente código definimos una interfaz que contiene los cuatros tipos de
miembros típicos de cualquier clase:
Sub Mostrar()
Event DatosCambiados()
End Interface
El primer miembro de esta interfaz, es un método de tipo Sub que no recibe
parámetros.
El siguiente método es una función que devuelve un valor de tipo String y recibe un
parámetro también de tipo cadena.
A continuación definimos una propiedad que devuelve una cadena.
Por último, definimos un evento.
Como podemos observar, lo único que tenemos que hacer es indicar el tipo de
miembro y si recibe o no algún parámetro o argumento.
Siempre que leemos sobre las interfaces, lo primero con lo que nos solemos encontrar
es que una interfaz es un contrato. Veamos que nos quieren decir con esa frase.
Tal como acabamos de ver, las interfaces solo definen los miembros, pero no el
código a usar en cada uno de ellos, esto es así precisamente porque el papel que
juegan las interfaces es el de solo indicar que es lo que una clase o estructura puede,
o mejor dicho, debe implementar.
Si en una clase indicamos que queremos "implementar" una interfaz, esa clase debe
definir cada uno de los miembros que la interfaz expone. De esta forma nos
aseguramos de que si una clase implementa una interfaz, también implementa todos
los miembros definidos en dicha interfaz.
Cuando una clase implementa una interfaz está firmando un contrato con el que se
compromete a definir todos los miembros que la clase define, de hecho el propio
compilador nos obliga a hacerlo.
Para poder utilizar una interfaz en una clase, o dicho de otra forma: para
"implementar" los miembros expuestos por una interfaz en una clase debemos
hacerlo mediante la instrucción Implements seguida del nombre de la interfaz:
Implements IPrueba
Y como comentábamos, cualquier clase que implemente una interfaz debe definir
cada uno de los miembros de esa interfaz, por eso es el propio Visual Basic el
encargado de crear automáticamente los métodos y propiedades que la interfaz
implementa, aunque solo inserta el "prototipo" de cada uno de esos miembros,
dejando para nosotros el trabajo de escribir el código.
Usando la definición de la interfaz IPrueba que vimos antes, el código que añadirá
VB será el siguiente:
Implements IPrueba
End Sub
Get
End Get
End Set
End Property
Public Function Saludo(ByVal nombre As String) As String _
Implements IPrueba.Saludo
End Function
End Class
Nota:
Si el lector antes ha utilizado las interfaces en VB6, esto no le resultará
extraño, ya que en ese lenguaje, cuando implementamos una interfaz
también se crean automáticamente las definiciones de los miembros que
contiene la interfaz, aunque el formato utilizado por VBScript/VB6 es:
<Nombre de la interfaz> <guión bajo> <nombre del método>, por
ejemplo: Private Sub IPrueba_Mostrar().
End Sub
Una vez que tenemos implementada una interfaz en nuestra clase, podemos acceder
a esos miembros de forma directa, es decir, usando un objeto creado a partir de la
clase:
prueba1.Mostrar()
O bien de forma indirecta, por medio de una variable del mismo tipo que la interfaz:
interfaz1 = prueba1
interfaz1.Mostrar()
Si las interfaces sirven para acceder de forma anónima a los métodos de un objeto, es
normal que en Visual Basic tengamos algún mecanismo para descubrir si un objeto
implementa una interfaz.
Para realizar esta comprobación podemos usar en una expresión If/Then la instrucción
TypeOf... Is, de forma que si la variable indicada después de TypeOf contiene el tipo
especificado después de Is, la condición se cumple:
interfaz1 = prueba1
interfaz1.Mostrar()
End If
En Visual Basic 2005, una misma clase puede implementar más de una interfaz. Para
indicar que implementamos más de una interfaz podemos hacerlo de dos formas:
Implements IPrueba
Implements IComparable
De cualquiera de las dos formas es válido implementar más de una interfaz, aunque
en ambos casos siempre debemos definir los miembros de cada una de esas
interfaces.
Como acabamos de comprobar, una misma clase puede implementar más de una
interfaz, y esto nos puede causar una duda:
¿Qué ocurre si dos interfaces definen un método que es idéntico en ambas?
En principio, no habría problemas, ya que el propio Visual Basic crearía dos métodos
con nombres diferentes y a cada uno le asignaría la implementación de ese método
definido en cada interfaz.
Por ejemplo, si tenemos otra interfaz que define el método Mostrar y la
implementamos en la clase Prueba, la declaración podría quedar de esta forma:
Sub Mostrar()
End Interface
End Sub
Aunque si ambos métodos hacen lo mismo, en este ejemplo mostrar algo, podríamos
hacer que el mismo método de la clase sirva para implementar el de las dos
interfaces:
Para ir acabando este tema nos queda por saber, entre otras cosas, dónde podemos
implementar las interfaces, es decir, en que tipos de datos podemos usar
Implements.
Debido a que una interfaz puede implementar otras interfaces, si en una clase
implementamos una interfaz que a su vez implementa otras, esa clase tendrá
definidas cada una de las interfaces, lo mismo ocurre con una clase que "se derive" de
otra clase que implementa alguna interfaz, la nueva clase también incorporará esa
interfaz.
Nota:
Cuando una interfaz implementa otras interfaces, éstas no se pueden
indicar mediante Implements, en lugar de usar esa instrucción debemos
usar Inherits.
Inherits IMostrar
Event DatosCambiados()
End Interface
Implements IPrueba2
End Sub
Get
End Get
End Set
End Property
Implements IPrueba2.Saludo
End Function
End Class
Si dejamos que Visual Basic cree los miembros, no tendremos problemas a la hora de
definirlos. Pero si lo hacemos manualmente, aunque dentro del IDE de Visual Basic,
éste nos ayuda indicándonos que interfaces implementamos y qué miembros son los
que se adecuan a la declaración que estamos usando, tal como podemos comprobar
en la Figura 2.02.16:
Figura 2.02.16 IntelliSense solo muestra los métodos que mejor se adecuan
a la declaración
Tal como comentamos al principio, el propio .NET está "plagado" de interfaces, cada
una de ellas tiene un fin concreto, por ejemplo, si queremos definir una clase que
pueda ser clasificada por el propio .NET, esa clase debe implementar la interfaz
IComparable, ya que el método Sort, (de la clase que contiene los elementos del tipo
definido por nosotros), que es el encargado de clasificar los elementos, hará una
llamada al método IComparable.CompareTo de cada uno de los objetos que queremos
clasificar, por tanto, si la clase no ha definido esa interfaz, no podremos clasificar los
elementos que contenga.
Implements IComparable
Me.Nombre = nombre
End Sub
Implements System.IComparable.CompareTo
Else
Return 0
End If
End Function
End Class
empleados.Add(New Empleado("Pepe"))
empleados.Add(New Empleado("Bernardo"))
empleados.Add(New Empleado("Juan"))
empleados.Add(New Empleado("Ana"))
empleados.Sort()
Next
Manejo de excepciones
· Manejo de excepciones
o Manejo de excepciones no estructuradas
o Manejo de excepciones estructuradas
§ Bloque Try
§ Bloque Catch
§ Varias capturas de errores en un mismo bloque Try/Catch
§ Evaluación condicional en un bloque Catch
§ Bloque Finally
o Captura de errores no controlados
Manejo de excepciones
En esta lección veremos cómo tratar los errores de forma estructurada, ya que el
"viejo" On Error sigue funcionando de la misma forma que en VBScript/VB6.
Como hemos comentado, en Visual Basic 2005 también podemos usar el "viejo"
sistema de tratamientos de errores, es decir, el "clásico" On Error... que ahora se
llama tratamiento de errores no estructurado. La forma de utilizar On Error es la
misma que en VBScropt/VB6, por tanto no vamos a entrar en detalles de cómo usar
esta forma de interceptar errores, solo aclarar un par de cosas que debemos tener en
cuenta:
La primera es: intentar no usar esta forma de detectar errores, es preferible, aunque
al principio cueste adaptarse, utilizar los errores estructurados.
La segunda es que no podemos usar los dos sistemas al mismo tiempo, por lo menos
en un mismo método o propiedad, o utilizamos On Error o utilizamos Try/Catch. De
todas formas, si utilizamos el IDE (entorno integrado) de Visual Basic, será el propio
compilador el que nos avise cuando mezclemos las dos formas de detectar los
errores.
Las excepciones en Visual Basic 2005 las podemos controlar usando las instrucciones
Try / Catch / Finally. Estas instrucciones realmente son bloques de instrucciones, al
estilo de If / Else.
Cuando queramos controlar una parte del código que puede producir un error lo
incluimos dentro del bloque Try. Si se produce un error, éste lo podemos detectar en
el bloque Catch. Por último, independientemente de que se produzca o no una
excepción, podemos ejecutar el código que incluyamos en el bloque Finally, para
indicar el final del bloque de control de excepciones lo haremos con End Try.
Veamos ahora con más detalle cada uno de estos bloques y que es lo que podemos
hacer en cada uno de ellos.
Bloque Try
En este bloque incluiremos el código en el que queremos comprobar los errores.
El código a usar será un código normal, es decir, no tenemos que hacer nada en
especial, ya que en el momento que se produzca el error se usará (si hay) el código
del bloque Catch.
Bloque Catch
Si se produce una excepción, ésta la capturamos en un bloque Catch.
En el bloque Catch podemos indicar que tipo de excepción queremos capturar, para
ello usaremos una variable de tipo Exception, la cual pude ser del tipo de error
específico que queremos controlar o de un tipo genérico.
Por ejemplo, si sabemos que nuestro código puede producir un error al trabajar con
ficheros, podemos usar un código como este:
Try
Catch ex As System.IO.IOException
Try
Catch ex As Exception
End Try
Aunque si no vamos usar la variable indicada en el bloque Catch, pero queremos que
no se detenga la aplicación cuando se produzca un error, podemos hacerlo de esta
forma:
Try
Catch
End Try
Esto nos permite poder indicar varios bloques Catch que detecten el mismo error,
pero cada una de ellas pueden tener diferentes expresiones indicadas con When.
Dim x, y, r As Integer
Try
x = CInt(Console.ReadLine())
y = CInt(Console.ReadLine())
r = x \ y
Catch ex As Exception
Console.WriteLine(ex.Message)
End Try
Bloque Finally
En este bloque podemos indicar las instrucciones que queremos que se ejecuten, se
produzca o no una excepción. De esta forma nos aseguramos de que siempre se
ejecutará un código, por ejemplo para liberar recursos, se haya producido un error o
no.
Nota:
Hay que tener en cuenta de que incluso si usamos Exit Try para salir del
bloque de control de errores, se ejecutará el código indicado en el
bloque Finally.
Nota:
De los eventos nos ocuparemos en la siguiente lección, pero como el
evento UnhandledException está directamente relacionado con la
captura de errores, lo mostramos en esta, aunque recomendamos al
lector que esta sección la vuelva a leer después de ver todo lo
relacionado con los eventos.
Este evento se "dispara" cuando se produce un error que no hemos interceptado, por
tanto podríamos usarlo para prevenir que nuestra aplicación se detenga o bien para
guardar en un fichero .log la causa de dicho error para posteriormente actualizar el
código y prevenirlo. Ya que cuando se produce el evento UnhandledException,
podemos averiguar el error que se ha producido e incluso evitar que la aplicación
finalice. Esa información la obtenemos mediante propiedades expuestas por el
segundo parámetro del evento, en particular la propiedad Exception nos indicará el
error que se ha producido y por medio de la propiedad ExitApplication podemos
indicar si terminamos o no la aplicación.
Nota:
Cuando ejecutamos una aplicación desde el IDE (entorno de desarrollo),
los errores no controlados siempre se producen, independientemente de
que tengamos o no definida la captura de errores desde el evento
UnhandledException. Ese evento solo se producirá cuando ejecutemos la
aplicación fuera del IDE de Visual Basic.
La forma que tienen nuestras clases y estructuras de comunicar que algo está
ocurriendo, es por medio de eventos. Los eventos no les son desconocidos a los
desarrolladores de VB6, ya que también existen y se pueden definir en ese lenguaje.
En Visual Basic 2005 se siguen usando de la misma forma que en VB6, aunque
seguramente siempre que hemos leído sobre el tema aparece la palabra delegado. Y
es que, aunque VB2005 nos oculte (o facilite) el trabajo con los eventos, éstos
siempre están relacionados con los delegados. En esta lección veremos que son los
delegados y que relación tienen con los eventos, también veremos que podemos tener
mayor control sobre cómo se interceptan los eventos e incluso cómo y cuando se
asocian los eventos en la aplicación cliente, aunque primero empezaremos viendo
cómo declarar y utilizar eventos en nuestros tipos de datos.
Eventos y delegados
· Eventos
o Interceptar los eventos de los controles de un formulario
§ Interceptar eventos en Visual Basic 6.0
§ Interceptar eventos en Visual Basic 2005
o Asociar un evento con un control
o Formas de asociar los eventos con un control
§ 1- Asociar el evento manualmente por medio de Handles
§ 2- Asociar el evento desde la ventana de código
§ 3- Asociar el evento desde el diseñador de formularios
o Asociar varios eventos a un mismo procedimiento
o Declarar una variable para asociar eventos con Handles
· Delegados
o ¿Qué ocurre cuando se asigna y se produce un evento?
o ¿Qué papel juegan los delegados en todo este proceso?
o Definición "formal" de delegado
o Utilizar un delegado para acceder a un método
En Visual Basic 2005 podemos usar los eventos de la misma forma que en Visual
Basic 6.0. Al menos en lo que se refiere a la forma de declararlos en nuestras clases y
cómo "lanzarlos", ya que la forma de interceptarlos en una aplicación ha cambiado un
poco, pero como veremos, incluso puede ser más fácil definir los métodos o
procedimientos que utilizamos para interceptarlos.
La declaración del código usado para interceptar el evento difiere un poco de VB6, tal
como podemos apreciar en el siguiente código:
Handles Button1.Click
End Sub
Lo primero que podemos notar es que en Visual Basic 2005 utiliza dos argumentos,
esto siempre es así en todos los eventos producidos por los controles. El primero
indica el control que produce el evento, (en nuestro ejemplo sería una referencia al
control Button1), y el segundo normalmente contiene información sobre el evento que
se produce. Si el evento en cuestión no proporciona información extra, como es el
caso del evento Click, ese parámetro será del tipo EventArgs. Sin embargo en otros
eventos el segundo argumento tendrá información que nos puede resultar útil, por
ejemplo para saber qué elemento se ha seleccionado en una lista o cual es el
elemento seleccionado en una rejilla Web. En la figura 2.04.1 podemos ver las
propiedades relacionadas con el evento RowDataBound de un control GridView:
Siguiendo con el código que intercepta el evento Click de un botón, podemos apreciar
que el IDE de Visual Studio 2005 añade al final de la declaración del procedimiento de
evento la instrucción Handles seguida del control y el evento que queremos
interceptar: Handles Button1.Click. Eesta la forma habitual de hacerlo en VB2005,
ya que, a diferencia de VB6, aquí no hay nombres "mágicos" para asociar un evento
con un control o incluso con el propio formulario, sino que esa asociación se hace de
forma explícita y la forma que tiene Visual Basic 2005 de hacerlo es usando la
cláusula Handles.
Nota:
En Visual Basic 2005 el nombre del procedimiento de evento no está
relacionado con el evento, a diferencia de VB6, en el que si que hay una
relación directa entre el evento a interceptar y el nombre del
procedimiento.
Aunque por defecto, el nombre usado sería el equivalente al de VB6, en
la nueva versión puede tener cualquier nombre.
Tal como resaltamos en la nota anterior, en Visual Basic 2005, el nombre asociado a
un evento puede ser el que queramos, lo realmente importante es que indiquemos la
instrucción Handles seguida del evento que queremos interceptar.
Si queremos escribir código para otros eventos podemos hacerlo de tres formas,
aunque la primera que explicaremos no será la más habitual, ya que debemos saber
exactamente qué parámetros utiliza el evento.
De esta forma el propio IDE será el que cree el "esqueleto" del procedimiento de
evento usando los parámetros adecuados.
Cuando utilizamos Handles para asociar eventos, podemos indicar que un mismo
procedimiento sirva para interceptar varios eventos. Veamos un caso práctico en el
que tenemos varios controles de tipo Button y queremos que cuando se pulsen
siempre se ejecute el mismo código. Podemos hacerlo indicando después de la
cláusula Handles todos los controles que queremos asociar con ese procedimiento.
En el siguiente código indicamos dos controles Button (uno arriba y otro abajo de la
página, por ejemplo):
ByVal e As System.EventArgs) _
End Sub
Esto es exactamente lo mismo que en Visual Basic 6.0, lo que ocurre es que cuando
trabajamos con formularios desde VB6, no nos tenemos que preocupar de este
detalle, en Visual Basic 2005 tampoco debemos preocuparnos, ya que el propio
diseñador de formularios lo hace por nosotros.
Aunque a diferencia de VB6, hay que hacerlo de forma explícita, ya que en la versión
anterior de Visual Basic no teníamos ningún control sobre como se definían o
declaraban los controles a usar en nuestro formulario, mientras que en esta nueva
versión siempre tendremos acceso a ello. No vamos a entrar en más detalles,
simplemente mostraremos cómo se declara el control Button1 para que exponga los
eventos:
End Sub
Nota:
Usar WithEvents y Handles es la forma más sencilla de declarar y usar
una variable que accede a una clase que produce eventos, pero no es la
única forma que tenemos de hacerlo en Visual Basic 2005, tal como
tendremos oportunidad de comprobar.
Para definir un evento en una clase usamos la instrucción Event seguida del nombre
del evento y opcionalmente indicamos los argumentos que dicho evento recibirá.
En el siguiente trozo de código definimos un evento llamado DatosModificados que no
utiliza ningún argumento:
Para producir un evento en nuestra clase, y de esta forma notificar a quién quiera
interceptarlo, simplemente usaremos la instrucción RaiseEvent seguida del evento
que queremos producir. Esto tampoco ha cambiado en Visual Basic 2005 con respecto
a VB6. Incluso cuando escribimos esa instrucción en el IDE, nos mostrará los distintos
eventos que podemos producir, tal como vemos en la Figura 2.04.04:
Figura 2.04.04 Lista de eventos que podemos producir
Tal como hemos estado comentando, la forma más sencilla de declarar una variable
para interceptar eventos es declarándola usando WithEvents y para interceptar los
eventos lo hacemos por medio de la instrucción Handles.
Esta forma es la más recomendada, no solo por la facilidad de hacerlo, sino porque
también tenemos la ventaja de que todas las variables declaradas con WithEvents se
muestran en la lista desplegable de la ventana de código.
En este caso, el uso de AddressOf es una forma "fácil" que tiene Visual Basic 2005 de
asociar un procedimiento de evento con el evento. Aunque por detrás, (y sin que nos
enteremos), realmente lo que estamos usando es un constructor a un delegado.
Como hemos comentado anteriormente los eventos son acciones que una clase puede
producir cuando ocurre algo. De esta forma podemos notificar a las aplicaciones que
hayan decidido interceptar esos mensajes para que tomen las acciones que crean
conveniente.
Visual Basic 2005 esconde al desarrollador prácticamente todo lo que ocurre cada vez
que decidimos interceptar un evento. Nosotros solo vemos una pequeña parte de todo
el trabajo que en realidad se produce, y el que no lo veamos no quiere decir que no
esté ocurriendo nada. También es cierto que no debe preocuparnos demasiado si no
sabemos lo que está pasando, pero si tenemos conciencia de que es lo que ocurre,
puede que nos ayude a comprender mejor todo lo relacionado con los eventos.
Intentemos ver de forma sencilla lo que ocurre "por dentro" cada vez que definimos
un método que intercepta un evento y cómo hace el Visual Basic para comunicarse
con el receptor de dicho evento.
1. Cuando Visual Basic se encuentra con el código que le indica que un método
debe interceptar un evento, ya sea mediante AddHandler o mediante el uso de
Handles, lo que hace es añadir la dirección de memoria de ese método a una
especie de array.
En la Figura 2.04.05 podemos ver un diagrama en el que un mismo evento lo
interceptan tres clientes, cuando decimos que un cliente intercepta un evento,
realmente nos referimos a que hay un método que lo intercepta y el evento
realmente guarda la dirección de memoria de ese método.
Figura 2.04.05 El evento guarda la dirección de memoria de cada método que
lo intercepta
Tanto el agregar nuevos métodos a esa lista como quitarlos, lo podemos hacer en
tiempo de ejecución, por medio de AddHandler y RemoveHandler respectivamente. Ya
que la instrucción Handles solo la podemos usar en tiempo de diseño.
Es más, podemos incluso indicar que un mismo evento procese más de un método en
una misma aplicación o que un mismo método sea llamado por más de un evento. Ya
que lo que realmente necesita cada evento es que exista un método que tenga una
"firma" concreta: la indicada al declarar el evento.
Veamos primero que papel tienen los delegados en todo este proceso y después
veremos con más detalle lo que "realmente" es un delegado.
Veamos que nos dice la documentación de Visual Basic 2005 sobre los delegados:
"Un delegado es una clase que puede contener una referencia a un método. A
diferencia de otras clases, los delegados tienen un prototipo (firma) y pueden
guardar referencias únicamente a los métodos que coinciden con su prototipo."
Esta definición, al menos en lo que respecta a su relación con los eventos, viene a
decir que los delegados determinan la forma en que debemos declarar los métodos
que queramos usar para interceptar un evento.
Es decir, el método que intercepte este evento debe ser del tipo Sub y no recibir
ningún parámetro.
Si nuestro evento utiliza, por ejemplo, un parámetro de tipo String, la definición del
delegado quedaría de la siguiente forma:
Public Delegate Sub NombreCambiadoEventHandler(ByVal nuevoNombre As
String)
Como podemos comprobar, Visual Basic 2005 nos permite definir los eventos de dos
formas distintas: definiendo un delegado y un evento que sea del tipo de ese
delegado o definiendo el evento con los argumentos que debemos usar.
Declaremos como declaremos los eventos, los podemos seguir usando de la misma
forma, tanto para producirlo mediante RaiseEvent como para definir el método que
reciba ese evento.
Ahora veamos brevemente cómo usar los delegados, en este caso sin necesidad de
que defina un evento.
Como hemos comentado, un delegado realmente es una clase que puede contener
una referencia a un método, además define el prototipo del método que podemos
usar como referencia. Sabiendo esto, podemos declarar una variable del tipo del
delegado y por medio de esa variable acceder al método que indiquemos, siempre
que ese método tenga la misma "firma" que el delegado. Parece complicado ¿verdad?
Y no solo lo parece, es que realmente lo es. Comprobemos esta "complicación" por
medio de un ejemplo. En este código, que iremos mostrando poco a poco, vamos a
definir un delegado, un método con la misma firma para que podamos usarlo desde
una variable definida con el mismo tipo del delegado.
End Sub
Ahora vamos a declarar una variable para que acceda a ese método.
Para ello debemos declararla con el mismo tipo del delegado:
Primer intento:
Como hemos comentado, los delegados realmente son clases, por tanto podemos
usar New Saludo y, según parece, deberíamos pasarle un nombre como argumento.
Algo así:
Pero esto no funciona, entre otras cosas, porque hemos comentado que un delegado
contiene (o puede contener) una referencia a un método, y "Pepe" no es un método
ni una referencia a un método.
Segundo intento:
Por lógica y, sobre todo, por sentido común, máxime cuando hemos declarado un
método con la misma "firma" que el delegado, deberíamos pensar que lo que
debemos pasar a esa variable es el método, ya que un delegado puede contener una
referencia a un método.
Pues tampoco.
Ya que el compilador "sabe" que saludando es una variable de tipo delegado y lo que
esa variable puede contener es una referencia a un método que tenga la misma firma
que la definición del delegado, en nuestro caso, que sea de tipo Sub y reciba una
cadena.
saludando("Pepe")
Realmente lo que hacemos con esa llamada es acceder al método al que apunta la
variable y como ese método recibe un argumento, debemos pasárselo, en cuanto lo
hacemos, el runtime de .NET se encarga de localizar el método y pasarle el
argumento, de forma que se ejecute de la misma forma que si lo llamásemos
directamente:
mostrarSaludo("Pepe")
Con la diferencia de que la variable "saludando" no tiene porqué saber a qué método
está llamando, y lo más importante, no sabe dónde está definido ese método, solo
sabe que el método recibe un parámetro de tipo cadena y aparte de esa información,
no tiene porqué saber nada más.
Así es como funcionan los eventos, un evento solo tiene la dirección de memoria de
un método, ese método recibe los mismos parámetros que los definidos por el evento
(realmente por el delegado), cuando producimos el evento con RaiseEvent es como si
llamáramos a cada uno de los métodos que se han ido agregando al delegado, si es
que se ha agregado alguno, ya que en caso de que no haya ningún método asociado
a ese evento, éste no se producirá, por la sencilla razón de que no habrá ningún
código al que llamar.
Para terminar con esta lección sobre los eventos y los delegados, vamos a ver otra
forma de definir un evento. Esta es exclusiva de Visual Basic 2005 y por medio de
esta declaración, tal como indicamos en el título de la sección, tendremos mayor
información sobre cómo se declara el evento, cómo se destruye e incluso cómo se
produce, es lo que la documentación de Visual Basic llama evento personalizado
(Custom Event).
Para declarar este tipo de evento, siempre debemos hacerlo por medio de un
delegado.
End AddHandler
End RemoveHandler
End RaiseEvent
End Event
Como podemos apreciar, debemos definir un delegado con la "firma" del método a
usar con el evento. Después definimos el evento por medio de las instrucciones
Custom Event, utilizando el mismo formato que al definir un evento con un delegado.
Dentro de la definición tenemos tres bloques, cada uno de los cuales realizará la
acción que ya hemos indicado en la lista numerada.
Nota:
Los eventos Custom Event solamente podemos definirlos e interceptarlos
en el mismo ensamblado.
Introducción
Esta es la definición que nos da la ayuda de Visual Basic sobre lo que es un atributo.
Atributos
· Atributos
o Tipos de atributos que podemos usar en una aplicación
§ Atributos globales a la aplicación
§ Atributos particulares a las clases o miembros de las clases
o Atributos personalizados
§ Acceder a los atributos personalizados en tiempo de ejecución
o Atributos específicos de Visual Basic
o Marcar ciertos miembros de una clase como obsoletos
Atributos
Como hemos comentado en la introducción, los atributos son etiquetas que podemos
aplicar a nuestro código para que el compilador y, por extensión, el propio .NET
Framework los pueda usar para realizar ciertas tareas o para obtener información
extra sobre nuestro código.
De hecho en cualquier aplicación que creemos con Visual Basic 2005 estaremos
tratando con atributos, aunque nosotros no nos enteremos, ya que el propio
compilador los utiliza para generar los metadatos del ensamblado, es decir, la
información sobre todo lo que contiene el ejecutable o librería que hemos creado con
Visual Basic 2005.
Por otra parte, el uso de los atributos nos sirve para ofrecer cierta funcionalidad extra
a nuestro código, por ejemplo, cuando creamos nuestros propios controles, mediante
atributos podemos indicarle al diseñador de formularios si debe mostrar ciertos
miembros del control en la ventana de propiedades, etc.
Como hemos comentado, existen atributos que son globales a toda la aplicación y
otros que podremos aplicar a elementos particulares, como una clase o un método.
Cuando aplicamos un atributo "particular", este debe estar en la misma línea del
elemento al que se aplica, aunque si queremos darle mayor legibilidad al código
podemos usar un guión bajo para que el código continúe en otra línea:
<Microsoft.VisualBasic.HideModuleName()> _
Module MyResources
Atributos personalizados
Además de los atributos que ya están predefinidos en el propio .NET o Visual Basic,
podemos crear nuestros propios atributos, de forma que en tiempo de ejecución
podamos acceder a ellos mediante las clases del espacio de nombres Reflection. Este
tema se sale un poco de la intención de este curso, pero simplemente indicaremos
que los atributos personalizados son clases que se derivan de la clase
System.Attribute y que podemos definir las propiedades que creamos conveniente
utilizar en ese atributo para indicar cierta información a la que podemos acceder en
tiempo de ejecución.
<AttributeUsage(AttributeTargets.All)> _
Inherits System.Attribute
'
Private _ModificadoPor As String
'
Get
Return _ModificadoPor
End Get
_ModificadoPor = value
End Set
End Property
'
Get
Return _Version
End Get
_Version = value
End Set
End Property
'
Get
Return _Fecha
End Get
_Fecha = value
End Set
End Property
End Class
<Autor(ModificadoPor:="Guillermo 'guille'", _
Version:="1.0.0.0", Fecha:="13/Abr/2005")> _
Nota:
Cuando utilizamos el atributo, en el constructor que de forma
predeterminada crea Visual Basic, los parámetros se indican por el orden
alfabético de las propiedades, pero que nosotros podemos alterar
usando directamente los nombres de las propiedades, tal como podemos
ver en el código de ejemplo anterior.
Sub Main()
tipo = GetType(PruebaAtributos)
atributos = Attribute.GetCustomAttributes(tipo)
End If
Next
End Sub
Visual Basic utiliza una serie de atributos para indicar ciertas características de
nuestro código, en particular son tres:
· COMClassAttribute
o Este atributo se utiliza para simplificar la creación de componentes COM
desde Visual Basic.
· VBFixedStringAttribute
o Este atributo se utiliza para crear cadenas de longitud fija en Visual Basic
2005. Habitualmente se aplica a campos o miembros de una estructura,
principalmente cuando queremos acceder al API de Windows o cuando
queremos usar esa estructura para guardar información en un fichero,
pero utilizando una cantidad fija de caracteres.
· VBFixedArrayAttribute
o Este atributo, al igual que el anterior, lo podremos usar para declarar
arrays de tamaño fijo, al menos si las declaramos en una estructura, ya
que por defecto, los arrays de Visual Basic son de tamaño variable.
En ocasiones nos encontraremos con que escribimos cierto código que posteriormente
no queremos que se utilice, por ejemplo porque hemos creado una versión
optimizada.
Si ese código lo hemos declarado en una interfaz, no deberíamos eliminarlo de ella,
ya que así romperíamos el contrato contraído por las clases que implementan esa
interfaz. En estos casos nos puede venir muy bien el uso del atributo <Obsolete>,
ya que así podemos informar al usuario de que ese atributo no debería ser usado. En
el constructor de este atributo podemos indicar la cadena que se mostrará al usuario.
En el siguiente código se declara un método con el atributo Obsolete:
Sub MostrarNombre()
Sub Mostrar()
End Interface
Los programadores de ASP.NET disponen de todo lo que "siempre" han disfrutado los
programadores de Windows: diseñadores visuales, asistencia avanzada contextual,
código compilado de alto rendimiento, transparencia acerca de dónde se ejecuta cada
parte del código, enlace a datos, rejillas, etc...
Si nos vamos a lo fundamental es posible crear una página ASP.NET usando el bloc de
notas y sin saber nada de la plataforma .NET y de sus diferentes espacios de nombre.
Las páginas de servidor de ASP.NET son en esencia archivos de texto que contienen
HTML y etiquetas y que tienen una extensión '.aspx'. Por ello se les denomina de
modo genérico páginas ASPX.
Al igual que las páginas ASP clásicas soportan el uso de etiquetas <% %> para
delimitar bloques de código. De hecho, por compatibilidad, se puede usar en gran
medida todo lo que conocemos de ASP 3.0, lo cual no quiere decir que sea lo más
recomendable. Sin embargo para familiarizarnos haremos un ejemplo sencillo.
Figura 3.1.1.- Página ASPX sencilla
El código de la figura no se distingue de una página ASP clásica salvo por la extensión
del archivo (.aspx en lugar de .asp). Sin embargo si navegamos hasta esta página
(ubicada en el raíz de nuestro servidor IIS) veremos que el resultado es el que
esperábamos:
Más código
Siguiendo con el ejemplo vamos a añadir un poco más de código para comprobar
hasta que punto son compatibles las páginas ASPX con el código ASP.
Este ejemplo nos ha servido para ver qué ASPX sigue siendo compatible en cierta
medida con ASP, y que sólo por este hecho ya mejoraremos la escalabilidad de las
páginas. De todos modos el cambio de la extensión del archivo sólo funcionará en las
páginas más sencillas. En código no trivial tenemos una probabilidad tendente a 1 de
que no haya esa suerte.
Además, aunque así fuera, no habríamos ganado demasiado: seguiríamos con código
de cliente y de servidor entremezclado y difícil de mantener y no tendríamos ninguna
de las ventajas que hemos mencionado antes.
Si bien podemos escribir código ASP.NET de la manera correcta sólo con el bloc de
notas, la mejor forma de desarrollar páginas Web con ASP.NET es usando Visual
Studio 2005, que como veremos enseguida nos ofrece una forma visual de trabajo
junto con una separación estricta entre el código y la interfaz de usuario, que es lo
que pretendíamos.
Visual Studio 2005 es el entorno de desarrollo de aplicaciones Web para la versión 2.0
de la plataforma .NET. Ofrece todo tipo de herramientas para facilitar el trabajo del
programador: diseñadores gráficos de páginas y clases, asistentes de uso de bases de
datos, un servidor web de desarrollo, ayuda a la escritura de código, y en general
todo lo que se espera de un entorno de desarrollo rápido moderno y mucho más
todavía.
Nota:
Las plantillas disponibles en el diálogo de nuevo proyecto web puede
diferir dependiendo de la versión de Visual Studio 2005 que utilice. Por
simplicidad se muestra el diálogo de la versión Visual Web Developer
Express, el más simple.
Existen diferentes lenguajes que nos sirven para crear el código de nuestras páginas.
Dado que en la práctica todos tienen las mismas capacidades escoger uno u otro es
una cuestión de elección personal. Dado que este curso está orientado
fundamentalmente a programadores que vienen de ASP o VB6, vamos a elegir Visual
Basic 2005 como lenguaje de todos nuestros ejemplos. En cualquier caso todo lo
explicado para éste es perfectamente válido para los otros lenguajes y le servirá igual
si se decide por ellos.
Explorando el entorno
Explorador de soluciones
Cuadro de herramientas
Figura 3.1.8.- Cuadro de herramientas y detalle de un algunos grupos de
éste.
Editor de propiedades
Creemos un ejemplo sencillo desde cero para ver cómo se trabaja. Luego
estudiaremos la estructura de los archivos generados para comprender su
funcionamiento. El ejemplo es el mismo que hemos creado en la primera lección del
módulo pero utilizando el modo de programar de ASP.NET y no el código "espaguetti"
típico de ASP clásico que hemos utilizado antes.
Desde Visual Studio cree un nuevo proyecto de sitio Web. Abra el diseñador de la
página por defecto que se crea (Default.aspx) haciendo doble click sobre ella. Añada
un control de tipo etiqueta (Label) en la parte superior y establezca su propiedad
Text con el valor "¡Bienvenido a ASP.NET! ", eligiendo un tipo de letra de tamaño
grande y color rojo.
Por fin añada una etiqueta más con el nombre lblSaludar, y ajuste su propiedad
Visible a False para que no se vea en el formulario web una vez que lo ejecutemos.
Cuando acabe el aspecto del formulario debería ser muy similar a éste:
Figura 3.1.9.- Aspecto del ejemplo tras haber añadido los controles.
Nota:
Si no tiene claro cómo hacerlo vea el primer vídeo de esta lección al pie
de este documento en donde se desarrolla el ejemplo completo.
Para saludar al usuario con el nombre que introduzca en el campo de texto debemos
responder a la pulsación del botón. En ASP clásico tendríamos que enviar un
formulario a otra página (o a la misma) y ver qué valores no es están pasando para
actuar en consecuencia. En ASP.NET esto no es necesario ya que trabajaremos según
el clásico paradigma orientado eventos, respondiendo a las acciones del usuario.
En este caso debemos interceptar la pulsación del botón por parte del usuario
¿verdad?. Pues lo único que tendremos que hacer es escribir un manejador para el
evento Click del botón, algo que resultará familiar e intuitivo a los programadores de
VB6. Para ello haga doble-clic sobre el botón en el diseñador. Esto hará que se abra el
editor de código y que automáticamente aparezca un manejador de eventos para el
evento Click, que es el predeterminado de los botones:
Al igual que en VB6 desde el código del evento (que se ejecutará en el servidor,
¡atención!) podemos hacer referencia a cualquier control de la página y acceder a sus
métodos y propiedades. De este modo se puede escribir el siguiente código simple:
Es decir, se concatena un saludo al nombre introducido en el campo de texto
asignándoselo como texto a mostrar a la etiqueta oculta, y se hace visible ésta
usando su propiedad Visible.
Si echamos un vistazo al código de la página generada veremos que, aparte del HTML
que es más o menos obvio que debería haber dados los controles que hemos
utilizado, existe también bastantes líneas de código JavaScript y algunos campos
ocultos.
Los campos ocultos se utilizan para almacenar información sobre la página y el código
JavaScript se ocupa de su mantenimiento y de enviar el formulario al servidor ante
determinadas acciones del usuario (simulando los eventos).
Nota:
A cada viaje de ida y vuelta de nuestra página al servidor como
consecuencia de un evento en el cliente se le denomina PostBack. Se
puede averiguar si la carga actual de la página es la primera o se trata
de un PostBack consultando el valor booleano de la propiedad
IsPostBack de la página (Me.IsPostback).
Por otra parte, para determinar qué evento se ha producido, se emplean también dos
campos ocultos y un poco de JavaScript:
En realidad todo el código se ejecuta en el servidor y, por poco intuitivo que sea para
un programador Web tradicional, el evento desencadenado por la pulsación se
gestiona en el servidor, no en el cliente. Veamos cómo funciona.
Para crear la interfaz de usuario sólo hemos tenido que arrastrar controles Web desde
el cuadro de herramientas al diseñador. Por detrás lo que ha estado ocurriendo es que
el código HTML de la página ha estado creciendo hasta ser como el siguiente:
Figura 3.1.15.- Código HTML de la interfaz de usuario ASPX.
Nota:
En las páginas ASPX sólo se recomienda el uso de un formulario, que es
además el formulario que incluye automáticamente el entorno de
desarrollo. Lo cierto es que no se trata de limitación alguna puesto que
la filosofía de desarrollo es completamente distinta a la tradicional y no
los vamos a necesitar.
El resto de elementos que aparecen son etiquetas HTML normales (p.ej<br/> para
cambio de línea) y unas etiquetas especiales que llevan el prefijo asp:. Este prefijo
indica que son controles web de ASP.NET, y como tales son objetos de las clases
contenidas en el espacio de nombres System.Web.UI.WebControls. Al compilar la
página ASP.NET instancia dichas clases y las pone a disposición de nuestro código
pasando todo ello inadvertido para nosotros.
Por otro lado existe un archivo con extensión .vb, dependiente, según el explorador
de proyectos, del archivo .aspx anterior.
Figura 3.1.16.- Archivo .vb de lógica de la aplicación
Éste contiene la "lógica" de la aplicación, es decir, lo que hace que una interfaz de
usuario se comporte de un determinado modo. En nuestro caso contiene el manejador
del evento con lo que deseamos que ocurra al presionar el botón. En una aplicación
real podría contener multitud de cosas más.
Nota:
Aunque es muy tentador abusar de la capacidad de crecimiento de estos
archivos de código, suele ser mucho más recomendable repartir toda
aquella funcionalidad que no se refiera a la interfaz de usuario (es decir,
lo que no sean eventos normalmente) en otros archivos y clases
desligados de páginas aspx. Veremos cómo hacerlo en breve en este
curso.
Desde este archivo de código podemos responder a cualquier evento de los controles
de interfaz de usuario o de la propia página, y acceder a sus métodos y propiedades.
Tras esta pregunta tan aparentemente filosófica se encuentra una respuesta muy
sencilla: la directiva de página @Page y la existencia de clases parciales en .NET
2.0.
Nota:
Inherits es un atributo nuevo en ASP.NET 2.0 y modifica el modelo
utilizado en Visual Studio 2002 y 2003 para crear código de lógica de
negocio para las páginas, denominado 'code-behind'. Si has trabajado
algo con estas versiones anteriores te sorprenderá ver este cambio y lo
mucho que con él se reduce el código necesario para crear las páginas
ASPX, ya que no hay que declarar los controles ni inicializarlos en el
código de lógica.
Nota:
A esta novedosa forma de separar (y al mismo tiempo unir en tiempo de
ejecución) la interfaz de la lógica hay quien la denomina "code-
beside", como homenaje al hasta ahora utilizado "code-behind" de
ASP.NET 1.x.
Nota:
Todo lo explicado es muy fácil de verificar si se accede a la carpeta
temporal de ASP.NET tal y como se demostró en el primer vídeo de este
módulo. En él encontraremos los archivos de código autogenerados por
.NET en los que podremos comprobar línea por línea todo lo que he
comentado. Se trata de una iniciativa muy didáctica.
Los controles de ASP.NET
ASP.NET ofrece una gran cantidad de controles que se pueden usar en los desarrollos
de aplicaciones Web. Durante la lección anterior hemos podido ver algunos de ellos en
funcionamiento mientras que supimos de la existencia de otros al verlos en el cuadro
de herramientas.
En esta lección vamos a conocer desde un punto de vista general los tipos de
controles existentes y aprenderemos, con más detalle, la utilización unos controles
muy útiles: los controles de validación.
· Controles HTML
o Controles HTML
o Jerarquía de controles HTML
· Controles Web
o Controles Web
o Adaptación al navegador
o Jerarquía de controles Web
o Controles propios
· Controles de validación
o Controles Web de validación
o Uso de los controles de validación
o Validadores personalizados
o Colocar el foco en el error
Los controles HTML
En el área de diseño del formulario es muy fácil distinguir los controles de servidor de
los HTML porque los primeros tienen un pequeño triángulo verde que los marca. En la
siguiente figura todos los controles se ejecutan en el servidor excepto el botón
"button" de la derecha.
Los controles HTML, en cualquier caso, son mucho más sencillos que los otros
controles Web. Tienen menos propiedades y eventos, los cuales se suelen
corresponder además con los mismos que tienen en HTML+Javascript. Son más
adecuados cuando no requerimos una gran flexibilidad y queremos cargar la página lo
mínimo posible.
Sus propiedades se corresponden con los atributos HTML del control correspondiente,
por lo que la nomenclatura utilizada no es consistente con la utilizada en el resto de la
plataforma ASP.NET.
Los controles Web que vienen con ASP.NET tienen otra característica que los hace
únicos y es la adaptación automática al navegador. ASP.NET detecta con qué cliente
se está accediendo (un navegador moderno o antiguo, un PDA, Internet Explorer o
Netscape, etc...) y de forma autónoma adapta el código que muestra a las
capacidades y restricciones concretas del navegador utilizado.
En esta nueva versión 2.0 de ASP.NET va un paso más allá permitiendo la adaptación
automática de los controles a diferentes navegadores y dispositivos incluso móviles
(teléfonos y PDA de cualquier marca). A esta característica se la conoce como
renderización adaptativa.
Aparte de los controles que vienen con ASP.NET 2.0 también es posible utilizar desde
nuestras aplicaciones cualquier otro control Web diseñado por terceras empresas.
Existen infinidad de ellos de todos los tipos, algunos realmente potentes.
Controles propios
Como no podría ser de otra manera, ASP.NET no nos limitará a la hora de crear
controles propios para reutilizar funcionalidad en nuestras aplicaciones o incluso para
venderlos a otras empresas.
· Controles Web: son controles como los que hemos visto hasta ahora y
equiparables en todos sus aspectos a los controles nativos de ASP.NET 2.0.
· Controles de usuario: permiten la reutilización de partes completas de la
interfaz de usuario y de la lógica asociada a ésta, aunque el soporte para
configurarlos en tiempo de diseño es mucho más reducido que en el caso de los
anteriores. Sin embargo son muy fáciles de crear y ofrecen un método sencillo
de encapsular funcionalidades que incluyan interfaz de usuario.
La creación de controles Web (primer tipo) es una cuestión compleja que se sale del
ámbito de este curso, por lo que no los estudiaremos. Sin embargo en la siguiente
lección veremos la forma de crear nuestros propios controles de usuario.
Por otra parte también se suele realizar una segunda comprobación en el servidor.
En aras de la seguridad, como máxima de cualquier desarrollo deberíamos tomar
siempre la siguiente: "Jamás deberé fiarme de nada que me llegue de un origen fuera
de mi control". En este caso aunque hayamos habilitado una primera validación en el
cliente con Javascript no debemos fiarnos en absoluto de que ésta se haya realizado.
Por ello debemos validar todos los datos siempre en el servidor. Si hay que quitar una
validación que sea siempre la del cliente.
Esta doble validación suele ser bastante engorrosa y supone un esfuerzo de desarrollo
adicional que sería estupendo poder obviar. Pensando en facilitarnos este tipo de
tareas ASP.NET nos ofrece los controles de validación.
Estos controles permiten definir reglas de validación en la entrada de datos. Dichas
reglas se asocian con otros controles que forman parte del formulario web, y se
combinan entre ellos para especificar múltiples restricciones sobre los datos
introducidos.
Las condiciones típicas son, por ejemplo, que un campo no se puede quedar vacío,
que tiene que estar comprendido dentro de un rango determinado o incluso que debe
cumplir con una expresión regular que indiquemos. Por supuesto es posible también
definir reglas propias personalizadas.
Una vez que definamos las reglas para un formulario los controles de validación se
encargan automáticamente de validarlas tanto en el cliente como en el servidor.
En el lado cliente se convertirán en código JavaScript muy parecido al que nosotros
usaríamos, actuando de primera barrera y evitando viajes innecesarios al servidor.
Las comprobaciones del lado del servidor nos evitan problemas cuando, por el motivo
que sea, no han actuado las validaciones en el cliente.
Nota:
Se puede desactivar la validación en el lado del cliente de un control
estableciendo su propiedad EnableClientScript a False. Podemos
deshabilitar la validación del lado cliente de todos los controles
estableciendo la propiedad ClientTarget de la página actual con la
cadena "DownLevel" desde el evento de carga de la página. Con ello sólo
se realizará la validación en el servidor.
Para hacer uso de uno de estos útiles controles basta con arrastrarlos al formulario.
Veremos que al hacerlo se muestran como si fueran etiquetas normales, aunque con
el texto de color rojo. Este es el aspecto que tendrán si se hace necesaria su
actuación. Mientras no se produce una situación en la que la validación fracasa serán
invisibles. Toda esta funcionalidad se consigue utilizando JavaScript, es decir, que no
se envía nada al servidor (no se hace un post-back).
Cada control de validación que arrastremos se debe asociar al control del que deberá
"estar pendiente". Por supuesto es posible arrastrar varios validadores y asociarlos a
un mismo control para así verificar varias condiciones. Lo contrario no es cierto, es
decir, no se puede usar un solo validador para verificar varios controles. El control a
verificar se asigna mediante la propiedad ControlToValidate del control de
validación.
Control Utilidad
RequiredFiledValidator Verifica que el control asociado no
se encuentra vacío.
RangeValidator Genera un mensaje de error
cuando el contenido de su control
asociado está fuera de un rango
de valores dado. Permite validar
intervalos numéricos (enteros o
decimales o monedas), fechas y
cadenas de texto.
RegularExpressionValidator Compara un texto introducido por
el usuario con una expresión
regular.
CompareValidator Permite comparar el valor
introducido por el usuario con una
constante o con el valor de la
propiedad de otro control.
CustomValidator Se usa para implementar lógica
de validación propia tanto en el
cliente como en el servidor.
No todos los controles se pueden validar con los controles de validación. De hecho
sólo un pequeño subconjunto de todos los controles Web son adecuados para un uso
conjunto. En cualquier caso los incluidos cubren la mayor parte de las necesidades
normales de introducción de datos, y son los siguientes:
Validadores personalizados
<script language="javascript">
args.IsValid = false;
else
args.IsValid = true;
</script>
Ahora todavía falta la validación en el servidor que de hecho es la más importante.
Su funcionamiento es igual de sencillo. Hay que gestionar el evento ServerValidate
del control CustomValidator. Este evento obtiene argumentos del tipo
ServerValidateEventArgs que son funcionalmente equivalentes a los que acabamos
de ver en el caso del cliente, es decir, disponen de las propiedades Value e IsValid.
Para rematar nuestro ejemplo con la validación en el servidor sólo es necesario
escribir el siguiente código VB.NET:
Nota:
Este control de validación personalizada ya existía en versiones
anteriores de ASP.NET. En éstas el evento de validación no se notificaba
cuando el control a validar estaba vacío. Para conservar la
compatibilidad el control CustomValidator de ASP.NET 2.0 trabaja de la
misma manera. Sin embargo es posible forzar la validación incluso con el
campo vacío si establecemos la propiedad ValidateEmptyText del
CustomValidator a True.
Otra acción muy común a la hora de validar datos en un formulario es colocar el foco
sobre el control que contiene información errónea. De este modo se facilita al usuario
la introducción del nuevo valor pues no tiene que activar el control con el ratón.
Podemos hacer que los controles de validación hagan esto por nosotros con sólo
establecer a True su propiedad SetFocusOnError. Esta característica es nueva en
ASP.NET 2.0.
· Controles de usuario
o Introducción
o Definición de la funcionalidad pública
o Uso de los controles de usuario
o Carga dinámica de controles de usuario
Controles de usuario
Los controles de usuario son tan fáciles de crear que, de hecho, ya conoce casi todo lo
que necesita para construirlos. Se crean exactamente igual que los formularios Web y
disponen de un diseñador visual idéntico que permite arrastrar otros controles sobre
su superficie. De hecho cualquier formulario Web (página ASPX) puede transformarse
directamente en un control reutilizable con sólo unos pocos cambios de sintaxis.
Para añadir un nuevo control de usuario pulse con el botón secundario sobre el nodo
raíz del proyecto en el explorador de soluciones y escoja la opción "Agregar
elemento...". En el diálogo que aparece (ya sobradamente conocido) seleccione el
icono correspondiente a Control de usuario Web, como se ilustra en la siguiente
figura:
Figura 3.3.1.- Diálogo para añadir un nuevo control de usuario.
Si se fija en la figura detenidamente verá que, salvo por el icono elegido, no hay
diferencia alguna con añadir un nuevo formulario Web. De hecho la única diferencia
existente en este punto es la extensión que se le otorgará al archivo resultante, que
es .ascx en lugar de .aspx.
La primera diferencia con una página ASPX la encontramos al ver las etiquetas que
constituyen la parte de interfaz de usuario del control. En los formularios aparece al
principio una directiva <%@Page %>, pero en los controles la directiva se llama
<%@Control %> si bien se usa de un modo muy similar:
Figura 3.3.2.- Código origen de un control de usuario sobre el que se han
arrastrado tres controles Web.
Otra diferencia fundamental de un control con una página es que hereda de la clase
UserControl y no de Page. Sin embargo ambas clases base heredan a su vez de la
clase TemplateControl, por lo que conservan multitud de características en común.
Todo a partir de ahora es exactamente igual que en el caso de los formularios Web.
Podemos arrastrar cualquier control Web desde el cuadro de herramientas sobre la
superficie del control, asignar sus propiedades y recibir post-backs que generan
eventos en los controles que hemos incluido.
Por supuesto, como en esencia un control de usuario no es más que una clase de
.NET, podemos extenderla añadiéndole nuestros propios métodos y propiedades.
Todos los miembros públicos que agreguemos estarán disponibles desde la página
que albergue al control del mismo modo que lo están las propiedades y métodos de
cualquier control Web normal. Esto es muy útil para encapsular el acceso a ciertas
funcionalidades que hayamos incluido.
Por supuesto los controles que coloquemos en la superficie del control se verán
adecuadamente en la página que lo contenga y se comportarán del modo esperado,
esto es, recibiendo eventos, conservando su estado en el ViewState, etc...
Ahora que ya sabemos crear controles de usuario veamos la forma de usarlos desde
los formularios Web.
Nota:
Visual Studio 2005 ofrece un mayor soporte en tiempo de diseño para
los controles de usuario que permite ver el contenido del control y
ajustar sus propiedades desde el explorador de propiedades. En
versiones anteriores de Visual Studio .NET lo único que se veía de estos
controles era un cuadro de color gris con su nombre y eran por tanto
más difícil trabajar con ellos y encajarlos en un diseño general.
Quizá el atributo más importante de esta directiva sea el último, TagPrefix. El valor
asignado a él será el que se utilice para distinguir de manera única un control de
usuario dentro de la página. De este modo se pueden utilizar sin problemas controles
de usuario con el mismo nombre en una misma página. Así, según la línea anterior
podríamos definir en la página un control del tipo Micontrol usando una sintaxis como
esta:
Las propiedades que hayamos definido para la clase Micontrol se pueden establecer
mediante atributos (al igual que ID en la línea anterior, por ejemplo) siempre que se
trate de tipos simples.
Podemos modificar la directiva Register para incluir un prefijo que nos guste más o
sea más descriptivo que el que Visual Studio ha puesto por defecto.
Dim c As Control
c = Me.LoadControl("Micontrol.ascx")
Me.Form.Controls.Add(c)
En lugar de usar un tipo genérico (Control) como en este fragmento también podemos
usarlo como el verdadero tipo del control y así llamar a sus métodos y propiedades
antes de añadirlo al formulario:
Dim c As Control
c = Me.LoadControl("Micontrol.ascx")
Me.Form.Controls.Add(miC)
En este ejemplo hemos usado el control con su verdadero tipo para poder asignar la
propiedad ValorInicial antes de agregarlo a la página.
Por supuesto una aplicación estará formada de todos modos por un número más o
menos elevado de páginas a las que se debe dirigir al usuario. Existen diversas
maneras de dirigir a un usuario hacia otra página o recurso de la aplicación.
Además si ajustamos la propiedad Text de este control ese será el texto que se
muestre para el enlace de la página. Es posible utilizar un gráfico en lugar de texto
para el enlace si se utiliza la propiedad ImageUrl.
Nota:
Existen controles especializados en crear árboles de navegación en una
página pero por debajo usan enlaces como éstos. Los estudiaremos en
un próximo módulo.
La otra manera de enviar a los usuarios a una página propia o ajena consiste en hacer
uso del método Redirect de la clase HttpResponse del contexto de llamada de la
página. Así podremos controlar desde un evento de servidor a dónde enviaremos al
usuario. Por ejemplo, si queremos enviarlo a una página diferente según lo que haya
escogido en un control de selección podríamos escribir algo similar a esto en el evento
de pulsación de un botón:
If opciones.ListIndex = 0 Then
Response.Redirect("opcion1.aspx")
Else
Response.Redirect("opcion2.aspx")
End If
ASP.NET 2.0 ha añadido una nueva funcionalidad denominada Cross Page Posting,
que permite precisamente esto. Para conseguirlo lo único que hay que hacer es
ajustar la propiedad PostBackUrl del control cuyos eventos queremos gestionar
desde otra página asignándole la ruta virtual de ésta última.
Los datos se reciben en la otra página pero todavía tenemos acceso a los datos de la
página original a través de la propiedad PreviousPage de la nueva. Se trata de un
objeto Page reconstruido a partir del ViewState recibido. Si la usamos así, de modo
genérico, tendremos que utilizar el método FindControl de la clase Page para
localizar cualquier control que hubiese en la página original. Por supuesto si ambas
páginas pertenecen al mismo espacio de nombres (o lo hemos declarado) podemos
forzar el uso de la página como la clase original de ésta usando CType y acceder
directamente a sus métodos, propiedades y controles.
También es posible determinar desde una página si los datos que está recibiendo son
de su propio Post-back o pertenece a otra página mediante la propiedad
IsCrossPagePostBack, que es muy similar a la propiedad IsPostBack que ya hemos
estudiado.
Esta técnica es de un uso poco frecuente pero se trata de una novedad poco conocida
que me ha parecido interesante incluir aquí.
A veces puede ser útil procesar el código de una página y justo después transferir el
control a otra página ejecutando también su código. El método Transfer de la clase
HttpServer ejecuta dinámicamente el código de una página desde otra cualquiera.
Server.Transfer("otrapagina.aspx")
En ASP clásico, por ejemplo, se solían agrupar las funciones de uso común dentro de
archivos de inclusión que luego se utilizaban en las diferentes páginas gracias a una
directiva <!-- #include -->. Si bien esto constituía una manera básica de reutilizar
código no ofrecía la flexibilidad de un lenguaje capaz de crear bibliotecas de objetos y
métodos.
Tal y como hemos estudiado anteriormente, cuando se solicita una página ésta se
compila de manera automática junto con su archivo de "code-beside" de forma que, a
medida que se accede a las diferentes partes de una aplicación se va compilando por
completo. Dadas las características de Visual Studio, el código residente en archivos
que no sean páginas o clases parciales de "code-beside" no se compila ya que jamás
navegamos por él ni se referencia desde otras páginas. La excepción a esta regla es el
código que coloquemos en la carpeta App_Code que se compila automáticamente al
comenzar la aplicación.
Por ello, una buena forma de reutilizar código entre páginas es agregar clases
especializadas a la carpeta App_Code. De hecho si presionamos con el botón
secundario sobre el proyecto en el explorador de soluciones y agregamos un nuevo
elemento de tipo Clase se nos mostrará una advertencia diciendo, grosso modo, que
debemos añadirla a App_Code si queremos que funcione. Incluso se crea
automáticamente la carpeta si no lo hemos hecho ya con anterioridad:
Una vez creadas nuevas clases en estas carpeta podemos añadirle métodos,
propiedades y campos para dotarlas de la funcionalidad que requiramos. Por supuesto
son clases normales de .NET por lo que podremos derivarlas de otras clases para
obtener funcionalidad "gratis", hacer que implementen interfaces o incluirlas dentro
de módulos o espacios de nombres para ordenarlas.
Nota:
Si dispone de la versión Visual Web Developer no podrá generar
bibliotecas DLL.
Le gustará saber que la plataforma .NET, y por lo tanto ASP.NET, ofrecen un potente
modelo de acceso a fuentes de datos. Se le conoce con el nombre genérico de
ADO.NET.
Nota:
No se deje engañar por el nombre: ADO.NET no casi nada que ver con el
anterior ADO utilizado en los tiempos de ActiveX y COM. Sí, dispone de
conexiones, comandos e incluso una clase que recuerda a los Recordset,
pero créame cuando le digo que es mejor que se olvide para siempre de
todos ellos. Tanto la filosofía de trabajo como la tecnología son
diferentes por completo y es mejor que utilice una estrategia de "ojos
limpios" para acercarse correctamente a la nueva tecnología.
El objeto más importante a la hora de trabajar con el nuevo modelo de acceso a datos
es el DataSet. Sin exagerar demasiado podríamos calificarlo casi como un motor de
datos relacionales en memoria. Aunque hay quien lo asimila a los clásicos Recordsets
su funcionalidad va mucho más allá como se verá en breve.
Arquitectura de ADO.NET
El concepto más importante que hay que tener claro sobre ADO.NET es su modo de
funcionar, que se revela claramente al analizar su arquitectura:
Figura 4.1.- Arquitectura de ADO.NET
La clase DataAdapter hace uso de las tres anteriores para actuar de puente entre la
capa conectada y la desconectada como veremos después.
Estas clases son abstractas, es decir, no tienen una implementación real de la que se
pueda hacer uso directamente. Es en este punto en donde entran en juego los
proveedores de datos. Cada origen de datos tiene un modo especial de
comunicarse con los programas que los utilizan, además de otras particularidades que
se deben contemplar. Un proveedor de datos de ADO.NET es una implementación
concreta de las clases conectadas abstractas que hemos visto, que hereda de éstas y
que tiene en cuenta ya todas las particularidades del origen de datos en cuestión.
Así, por ejemplo, las clases específicas para acceder a SQL Server se llaman
SqlConnection, SqlCommand, SqlDataReader y SqlDataAdapter y se
encuentran bajo el espacio de nombres System.Data.SqlClient. Es decir, al
contrario que en ADO clásico no hay una única clase Connection o Command que se
use en cada caso, si no que existen clases especializadas para conectarse y recuperar
información de cada tipo de origen de datos.
Nota:
El hecho de utilizar clases concretas para acceso a las fuentes de datos
no significa que no sea posible escribir código independiente del origen
de datos. Todo lo contrario. La plataforma .NET ofrece facilidades de
escritura de código genérico basadas en el uso de herencia e
implementación de interfaces. De hecho la versión 2.0 de .NET ofrece
grandes novedades específicamente en este ámbito.
Existen proveedores nativos, que son los que se comunican directamente con el
origen de datos (por ejemplo el de SQL Server o el de Oracle), y proveedores
"puente", que se utilizan para acceder a través de ODBC u OLEDB cuando no existe
un proveedor nativo para un determinado origen de datos.
Nota:
Estos proveedores puente, si bien muy útiles en determinadas
circunstancias, ofrecen un rendimiento menor debido a la capa
intermedia que están utilizando (ODBC u OLEDB). Un programador novel
puede sentir la tentación de utilizar siempre el proveedor puente para
OLEDB y así escribir código compatible con diversos gestores de datos
de forma muy sencilla. Se trata de un error y siempre que sea posible es
mejor utilizar un proveedor nativo.
Una vez que ya se han recuperado los datos desde un origen de datos la conexión a
éste ya no es necesaria. Sin embargo sigue siendo necesario trabajar con los datos
obtenidos de una manera flexible. Es aquí cuando la capa de datos desconectada
entra en juego. Además, en muchas ocasiones es necesario tratar con datos que no
han sido obtenidos desde un origen de datos relacional con el que se requiera una
conexión. A veces únicamente necesitamos un almacén de datos temporal pero que
ofrezca características avanzadas de gestión y acceso a la información.
Por otra parte las conexiones con las bases de datos son uno de los recursos más
escasos con los que contamos al desarrollar. Su mala utilización es la causa más
frecuente de cuellos de botella en las aplicaciones y de que éstas no escalen como es
debido. Esta afirmación es especialmente importante en las aplicaciones Web en las
que se pueden recibir muchas solicitudes simultáneas de cualquier parte del mundo.
Finalmente otro motivo por el que es importante el uso de los datos desconectado de
su origen es la transferencia de información entre capas de una aplicación.
Éstas pueden encontrarse distribuidas por diferentes equipos, e incluso en diferentes
lugares del mundo gracias a Internet. Por ello es necesario disponer de algún modo
genérico y eficiente de poder transportar los datos entre diferentes lugares, utilizarlos
en cualquiera de ellos y posteriormente tener la capacidad de conciliar los cambios
realizados sobre ellos con el origen de datos del que proceden. Todo esto y mucho
más es lo que nos otorga el uso de los objetos DataSet, núcleo central de la capa
desconectada de ADO.NET.
Nota:
Otra interesante características de los DataSet es que permiten
gestionar simultáneamente diversas tablas (relaciones) de datos, cada
una de un origen diferente si es necesario, teniendo en cuenta las
restricciones y las relaciones existentes entre ellas.
Los DataSet, como cualquier otra clase no sellada de .NET, se pueden extender
mediante herencia. Ello facilita una técnica avanzada que consiste en crear tipos
nuevos de DataSet especializados en la gestión de una información concreta (por
ejemplo un conjunto de tablas relacionadas). Estas nuevas tipos clases se denominan
genéricamente DataSet Tipados, y permiten el acceso mucho más cómodo a los
datos que representan, verificando reglas de negocio, y validaciones de tipos de datos
más estrictas.
Nota:
Aunque este es el comportamiento habitual de una aplicación de datos
existen casos en los que no es recomendable almacenar en memoria (en
un DataSet) todos los resultados de una consulta, bien por ser muchos
registros o por contener datos muy grandes. En este tipo de casos se
puede usar u objeto DataReader directamente para leer la información,
tratarla y no almacenarla en lugar alguno. De todos modos lo más
frecuente es realizar el proceso descrito.
Así, por ejemplo, el método Fill de un DataSet se utiliza para introducir los resultados
de una consula dentro de un DataSet para luego trabajar con ellos sin preocuparnos
de su origen. Del mismo modo su método Update se utiliza para conciliar
automáticamente con el origen de datos los datos modificados en un DataSet
mientras no había conexión.
Otras clases dependientes de DataSet
Como hemos dicho antes un DataSet podría asimilarse a un pequeño gestor de datos
en memoria. Como tal un DataSet permite mantener diversas tablas así como las
relaciones entre ellas, incluso forzando que se cumplan restricciones de creación y
actualización, como en una base de datos "real". Para ello se apoya en el uso de otras
clases especializadas que son las siguientes:
La mayor parte de los controles que podemos arrastrar sobre una página ASPX se
pueden vincular a los objetos DataSet, DataTable y DataReader o a informaciones
concretas contenidas en éstos.
Ello facilita mucho el trabajo con datos desde la interfaz de usuario ya que no hay que
molestarse en generar tablas con ellos, escribir JavaScript o proporcionar complejos
medios propios para permitir su edición o navegación si hacemos un uso adecuado de
la vinculación y los controles disponibles.
En este módulo veremos también lo sencillo que resulta crear interfaces para explotar
los datos desde una página Web.
Acceso a datos manual
La mayor parte de las consultas que se lanzan contra una base de datos suelen
utilizarse para obtener un conjunto de registros para tratar. Este tipo de consultas
suelen ser expresiones SQL de tipo SELECT. El siguiente fragmento de código muestra
los pasos necesarios para mostrar en una página los registros resultantes de una
consulta:
No se trata de un código optimizado (es más bien burdo) pero nos ayudará a
entender perfectamente el proceso. Los datos los obtendremos de la conocida base de
datos de ejemplo Northwind (que viene con todas las versiones de SQL Server).
Nota:
Para poder escribir código de acceso a datos en nuestro módulo
debemos agregar referencias a los espacios de nombres que contienen
las clases que vamos a utilizar. Para ello usamos las dos sentrencias
Imports siguientes:
Una vez creado el objeto con el que nos conectaremos hay que definir el comando a
lanzar a la base de datos. Para ello se utiliza un objeto SqlCommand. Las propiedades
básicas que hay que establecer para éste son la consulta que se lanzará (propiedad
CommandText) y la conexión que se empleará para lanzarla (propiedad
Connection) que es lo que se refleja en las líneas 6 y 7.
Ahora que ya sabemos cómo nos conectaremos y qué queremos obtener debemos
lanzar la consulta y recoger el resultado de alguna manera.
1. Abrir la conexión.
2. Crear una variable para contener una referencia a un objeto de la clase
DataReader que es el que nos permitirá acceder a los resultados. Fíjese en que
no se puede instanciar un DataReader (la declaración no lleva la palabra clave
New).
3. Se obtiene el resultado mediante el método ExecuteReader, recogiéndolo en la
variable (dr) recién declarada.
4. Se procesan los resultados (líneas 14-18).
5. Se cierra la conexión.
La cláusula Using
De este modo, con la cláusula Finally nos aseguramos que siempre se va a cerrar la
conexión.
De todos modos escribir este código es algo tedioso sobre todo si queremos que la
excepción se replique y sólo metemos la cláusula Finally por el hecho de cerrar la
conexión.
Para facilitar el trabajo VB.NET en .NET 2.0 incluye una cláusula especial denominada
Using que habilita la destrucción automática de los objetos a los que se hace
referencia. Así el código anterior quedaría simplemente:
Al terminar la cláusula Using (aunque haya un error por medio) se llama de manera
automática al método Dispose del objeto utilizado (en este caso una conexión). Entre
otras cosas este método se encarga de cerrar el objeto si estaba abierto, por lo que
no nos tendremos que preocupar de este aspecto.
Grupos de registros
Ventajas e inconvenientes
El código anterior, aunque sencillo, es un poco lioso y el uso de los DataReader está
algo limitado dada su idiosincrasia (de sólo lectura y hacia adelante). Este código es
adecuado si no necesitamos almacenar los resultados de la consulta en memoria ni
regresar sobre ellos una vez procesados una primjera vez. También es muy útil para
obtener resultados con miles o millones de registros que queremos tratar
secuencialmente pero no almacenar en memoria.
Sin embargo para un uso cotidiano se trata de un código muy poco útil y complicado
de utilizar salvo para cosas muy sencillas. Además sólo hemos utilizado clases de la
capa conectada de ADO.NET. Todavía debemos aprender a obtener los resultados
dentro de un DataSet para su explotación de manera cómoda. Hay que tender un
puente entre ambos mundos (conectado y desconectado): el DataAdapter.
DataAdapter: puente entre mundos
El objeto DataSet
Los objetos DataSet contienen a su vez objetos DataTable que son los que contienen
realmente los datos. Para acceder a las tablas de un DataSet se utiliza su colección
Tables. Se puede acceder a las tablas por posición (números enteros) o por nombre
si lo sabemos.
En un ejemplo sencillo como el anterior (y por otro lado uno de los más comunes) se
crea una única tabla en el DataSet de nombre "Table1" y posición 0.
Con esta información resulta muy sencillo tratar los datos de una consulta. Podemos
acceder directamente a cualquier registro de la tabla usando su posición en la
colección de filas. Por ejemplo para acceder al quinto registro de una tabla basta con
escribir:
Dim dr As DataRow
dr = ds.Tables(0).Rows(4)
ds.Tables(0).Rows(4)("CompanyName")
que devolverá un objeto del tipo adecuado para el campo que representa (una
cadena, un objeto de fecha, un booleano, etc...).
Nota:
Es muy sencillo definir objetos DataTable que dispongan de los campos
que deseemos sin depender de origen alguno de datos. Emplee el
método Add de la colección Columns para crear nuevos campos, algunos
de los cuales pueden ser incluso derivados mediante una fórmula de los
valores de otros. Esto permite definir estructuras de almacenamiento a
medida en memoria sin preocuparnos de usar una base de datos para
ello.
Es posible moverse con libertad entre los registros de una tabla y sus registros
relacionados en otras tablas. Y sobre todo, se pueden vincular con elementos de la
interfaz gráfica para mostrar los datos automáticamente.
Consultas parametrizadas
Las consultas simples como la que acabamos de utilizar en los ejemplos anteriores
son muy raras. En la realidad las consultas son mucho más complejas, suelen
intervenir varias tablas y dependen de diversos parámetros que le añaden
condiciones.
Nota:
Cada proveedor de datos utiliza su propia convención para indicar la
posición de los parámetros en una consulta. En el caso de SQL Server se
indican con una arroba '@' seguida de un identificador. En otros
proveedores no se puede definir nombre para los parámetros, sólo se
marca su posición con un caracter especial.
Con lo que hemos visto hasta ahora ya estamos en condiciones de escribir código
para realizar altas, bajas y modificaciones de registros. Al fin y al cabo éstas son
simplemente consultas SQL del tipo adecuado (INSERT, DELETE o UPDATE) que se
deben enviar al servidor.
Así pues, para crear un nuevo cliente podemos escribir una función como la siguiente:
Es un código muy similar al anterior que realizaba una selección de datos. En este
caso se ha definido una consulta de inserción con tres parámetros. En lugar de usar
ExecuteReader o un DataAdapter en este caso se utiliza el método ExecuteNonQuery.
Éste lanza la consulta (es decir, se inserta el nuevo registro) y devuelve el número de
registros afectados por la consulta (que en el caso de una inserción siempre es 1 si se
inserta correctamente o 0 si ha habido un error y lo capturásemosr).
Trabajando desconectados
La actualización de datos es más sencilla aún ya que basta con acceder directamente
al registro que nos interesa modificar y cambiar los valores de sus campos. Por
ejemplo, para modificar la dirección del cliente cuyos datos están en el quinto registro
de nuestra tabla sólo hay que escribir:
Por fin, para eliminar un registro sólo hay que usar su método Delete, así:
Es muy fácil trabajar con los Dataset en memoria de este modo. Sólo hay un
"pequeño" problema: los cambios se realizan en memoria pero, al no estar vinculado
el DataSet con origen de datos alguno, no los veremos reflejados en la base de datos
que es lo que buscamos.
Una vez definidos los tres parámetros de alta, baja y modificación sólo resta llamar a
Update para que el DataAdapter se ocupe de toda la sincronización.
Ventajas
Este modelo está lleno de ventajas aunque a primera vista pueda parecer algo
engorroso.
Nota:
Luego veremos que podemos usar las herramientas que nos proporciona
Visual Studio 2005 para definir de manera automática los comandos de
manipulación de datos sin necesidad de pasar el trabajo de hacerlo
manualmente.
Para empezar podemos trabajar con los datos en total libertad sin preocuparnos de si
existe conexión o no con el origen y aunque el DataSet se manipule en una ubicación
física a miles de kilómetros del origen y desconectado de éste o los cambios se
almacenen a disco y se concilien días más tarde.
Se pueden realizar multitud de modificaciones en los datos y luego conciliarlas
simultáneamente en lugar de hacerlo en tiempo real de una en una.
El paso de datos entre capas y funciones se simplifica. Lo habitual antes era definir
funciones con tantos parámetros como datos se quisieran modificar en un registro.
Por ejemplo, para insertar un registro en una tabla que tiene 20 campos se definía
una función con 20 parámetros (muchos de ellos opcionales) o, en el mejor de los
casos, se pasaba una clase creada a medida que representaba lo valores del registro.
Ahora basta con pasar un DataSet, un DataTable o un dataRow que ya contiene toda
la información que necesitamos saber sobre los registros y su tabla asociada.
Lo mejor es que es posible saber mediante ciertas propiedades qué registros han
cambiado (nuevos, modificados, borrados) y mover entre capas exclusivamente
estos. La propiedad HasChanges de los DataSet, DataTable y DataRow nos informa
de si el objeto ha sufrido cambios de algún tipo.
Valor Significado
Added Registros que no estaban
originalmente.
Deleted Registros que se han eliminado
Modified Registros cuyos valores se han
modificado
UnChanged Registros que no se han
modificado
Detached Registros que se han desasignado
de una tabla (pero no borrado con
Delete)
Ahora que ya hemos visto la forma de trabajo manual con ADO.NET y dominamos los
fundamentos, vamos a sacar partido a todas las ventajas que nos proporciona un
entorno como Visual Studio 2005 que, como veremos, nos permiten hacer casi
cualquier tarea de datos sin necesidad de escribir código.
Orígenes de datos
ASP.NET 2.0 ofrece los siguientes controles de origen de datos que se pueden ver en
la figura anterior:
Control Descripción
SqlDataSource Enlaza con cualquier base de
datos para que exista un
proveedor de ADO.NET.
AccessdataSource Esta especializado en trabajar
con bases de datos Microsoft
Access.
ObjectDataSource Se enlaza con objetos de
negocio y capas personalizadas
de acceso a datos.
XmlDataSource Trata datos contenidos en
documentos XML.
SiteMapDataSource Se enlaza con la jerarquía de
clases expuesta por el modelo
de navegación de sitios de
ASP.NET 2.0.
Concurrencia optimista
Nota:
En mi opinión debería llamarse "concurrencia realista" ya que, lo cierto
es que si se analiza con detenimiento la posibilidad de conflicto en un
sistema grande tiende a ser realmente pequeña en la mayoría de los
casos. Y de todos modos el sobreescribir cierta información no suele ser
un problema grave salvo cuando hablamos de cuestiones de dinero,
facturas y similares.
Es decisión suya qué tipo de actualización utilizar pero en la mayor parte de los casos
usará seguramente la pesimista que, de hecho, es la que usted utiliza normalmente si
escribe las funciones a mano de manera independiente.
Nota:
Si usted ya conoce los controles enlazados a datos de ASP.NET 1.x como
el DataGrid, el DataRepeater, etc... estos controles le resultarán más
cómodos de utilizar pues al contrario que con aquellos no hay que
escribir código alguno. Aunque estos controles "antiguos" no aparecen
en el cuadro de herramientas siguen estando soportados y los puede
seguir utilizando. Incluso si lo desea puede añadirlos al cuadro de
herramientas. De todos modos se recomienda utilizar el nuevo modelo
declarativo de acceso a datos.
Uso de los controles de datos en la práctica
La clase DataSet, como cualquier otra clase no sellada de .NET, puede ser extendida
mediante herencia para añadirle nuevas funcionalidades y aprovechar las ya
existentes. Si creamos una nueva clase que herede de DataSet y ésta la
especializamos en el tratamiento de un conjunto de datos determinado que
conocemos de antemano nos encontramos un DataSet especializado.
Por ejemplo, podemos crear un DataSet especial que tengan en cuenta las
particularidades de los datos que maneja para validarlos antes de permitir su
inserción, que verifique las relaciones con otros datos o que los transforme o controle
el acceso a los mismos. Nosotros sólo tendríamos que ocuparnos de estas tareas
dejando a la clase DataSet de la que hemos heredado todos los puntos complejos que
tienen que ver con la gestión de datos pura y dura.
Esta es, en esencia, la idea que subyace bajo los DataSet tipados de Visual Studio
2005. Se trata de clases especializadas derivadas de DataSet que ofrecen una forma
más rápida y sencilla de acceder a los datos que albergan. Además Visual Studio nos
permite crear este tipo de DataSet de forma visual y usando asistentes. En el vídeo se
ilustra la manera de conseguirlo.
Los DataSet tipados parten del conocimiento preciso de la estructura de una base de
datos para definir su funcionalidad. Esta es su principal diferencia con los DataSet
normales puesto que éstos son genéricos y no saben nada acerca de los datos que
albergan. Los tipados sólo sirven para albergar una información muy concreta. Ganan
en especialización y pierden en versatilidad.
Para agregar un DataSet tipado a nuestro proyecto sólo hay que presionar con el
botón secundario sobre la carpeta App_Code y en el diálogo que aparece elegir el
icono de DataSet. La extensión del archivo generado es '.xsd' porque lo que en
realidad albergan es un esquema XML que define la estructura de los datos en los que
se van a especializar.
Una vez agregado el DataSet aparece una superficie de diseño y un asistente como el
de la figura.
Truco:
Podemos ver el código que se genera de manera automática para crear
el DataAdapter si hacemos doble-clic sobre él desde el examinador de
objetos de Visual Studio (CTRL+ALT+J). Esto hará que se abra el archivo
de código auto-generado por ASP.NET desde la ubicación real de
ejecución (normalmente una ruta del estilo
C:\Windows\Microsoft.NET\....). Es muy interesante echarle un vistazo a
este código para aprender el funcionamiento interno de los DataSet
tipados.
Cada una de las tablas del DataSet lleva asociado como mínimo un TableAdapter.
Entre los dos objetos (el DataTable y el o los TableAdapter relacionados) se reparten
el trabajo. El DataTable tipado mantiene en memoria la información y el TableAdapter
actúa de puente con la tabla real en la base de datos.
Nota:
Como sabemos (y veremos en el vídeo también) las tablas de un
DataSet no tienen porqué coincidir con tablas reales de una base de
datos ya que pueden ser resultados obtenidos de una consulta compleja
que involucre a varias tablas. En estos casos es más complicada la
actualziación y se suelen usar únicamente para recuperar datos. la
alternativa habitual es tratar de replicar la estructura física de la base de
datos en la estructura en memoria del DataSet de modo que se tiene
acceso estructurado a la misma información y gracias a las relaciones y
restricciones se conserva la consistencia de los datos tambiñen estando
desconectados.
El DataSet tipado dispone de propiedades que coinciden con los nombres de los
objetos que contienen. Así, por ejemplo, si tenemos una tabla "Clientes" con un
campo "Nombre" podemos acceder a él directamente con este código:
ds.Clientes(0).Nombre
que nos daría el nombre del primer cliente de la tabla de clientes en el DataSet 'ds'.
esta propiedad nombre además ya sería un campo de tipo String que es el tipo
adecuado para la información albergada, por lo que se simplifica mucho su uso.
ds..Tables(0).Rows(0)("Nombre").ToString()
La cosa no termina aquí ya que además se definen clases específicas para representar
los registros de las tablas. Por ejemplo si la tabla se llama 'Clientes' existirá una clase
ClientesRow que dispone de propiedades con el mismo nombre y tipo que los campos
correspondientes en la tabla de la base de datos y que hemos usado en la línea de
ejemplo. Así, para añadir un cliente podríamos escribir:
cliente.Nombre = "Pepe"
....
ds.Clientes.AddClientesRow(cliente)
Nótese que el método Add del DataTable se ha sustituido por uno con nombre
especializado que nos ayuda a saber mejor por donde pisamos, pero su función es
idéntica.
clientes.Clientes(0).Nombre = "Pepe"
....
o también usando el método GetData para obtener la tabla directamente si sólo nos
interesa esa parte concreta del DataSet (que puede constar de varias tablas):
clientes(0).Nombre = "Pepe"
....
Lo más habitual cuando se crea una aplicación o un sitio Web es que las páginas que
lo conforman sean todas bastante parecidas o al menos que existan varios grupos de
páginas similares que sólo varían ciertos contenidos entre ellas. Por ejemplo, puede
haber una categoría de páginas para mostrar artículos en el que todas son iguales
excepto por el contenido del propio artículo en su parte central, mientras que en otra
zona de la aplicación el diseño es completamente diferente pero sus páginas se
parecen todas entre sí.
Tradicionalmente para conseguir esta similitud entre páginas había que crearlas
individualmente o recurrir a artificios propios como por ejemplo el de utilizar archivos
de inclusión para renderizar ciertas partes de las páginas desde un mismo origen en
disco. Aún en este último caso la capacidad de modificación era limitada y
normalmente se reducía a las cabeceras y pies de las páginas y poco más. En el
primero de los casos (retocar una a una) cualquier cambio estético de un sitio
medianamente grande era poco menos que una locura de realizar.
ASP.NET 2.0 ofrece una nueva característica destinada a paliar esta tradicional
carencia y permite definir páginas cuyo aspecto y funcionalidad deriva de unas
páginas especiales comunes llamadas Páginas principales o Master Pages.
Nota:
Aunque normalmente soy partidario de utilizar los términos en castellano
siempre que los haya, en este caso haré una excepción y durante el
resto del texto emplearé el término anglosajón Master Pages (o MP) para
referirme a esta característica. El motivo es que este término es el más
aceptado y el que veremos con más frecuencia.
Una Master Page proporciona una forma de definir una estructura e interfaz comunes
para un grupo de páginas pertenecientes a un mismo sitio Web. Esta estructura
común se almacena en un único archivo independiente. Ello facilita mucho su
mantenimiento puesto que, para actualizar todas las páginas que lo utilizan, basta
con editar dicho archivo.
Una MP es en realidad como una página ASPX normal que contiene código, elementos
HTML y controles Web de servidor. Sin embargo posee una extensión diferente
(.master) y utilizan una directiva <% @ master %> en lugar de una directiva <% @
page %>. Por lo demás se pueden considerar prácticamente equivalentes. Esto es
importante porque significa que ya sabemos todo lo necesario para crearlas.
Una página ASPX normal puede derivar su estructura a partir de una MP simplemente
añadiendo un atributo MasterPageFile a su directiva de página, así:
Para agregar una Master Page a nuestro proyecto sólo hay que elegir el icono Página
Principal en el diálgo de agregar nueva referencia de cualquier carpeta del mismo:
Cuando añadimos una nueva página ASPX a nuestro proyecto y existe al menos una
Master Page, podemos marcar una opción para que, antes de crearla, nos permita
seleccionar de qué MP derivará:
Al editar una página que deriva de una Master Page aparece el aspecto y estructura
de la página principal en el diseñador, pero sólo se pueden tocar las partes
correspondientes a los comodines de contenido.
Una Master Page a su vez puede derivar de otra que previamente hayamos definido,
por lo que heredará la estructura y contenidos de ésta. Al igual que en el caso de las
páginas normales sólo hace falta establecer el atributo MasterPageFile.
Esta característica se suele utilizar para definir en una de ellas la estructura general
del sitio Web. En otra de las MP se define únicamente la estructura de los contenidos
que contiene la estructura general.
La única "pega" que tiene el uso de Master Pages anidadas es que no están
soportadas por el diseñador de Visual Studio, por lo que habrá que añadir los
controles directamente a mano desde la vista de marcado de la página. Siempre
podremos diseñarlas visualmente antes de hacerlas derivar de una Master Page
anidada y así salvar esta limitación.
Acceso a los elementos de una Master Page
Es posible acceder a los controles y elementos de una página principal desde el código
de una página derivada a través de una directiva especial llamada MasterType. Sólo
hay que indicar la ruta de la Master Page a la que queremos acceder, así:
Una vez hecho esto podemos acceder a los elementos de la página de la que deriva la
actual a través de su propiedad Master.
Por ejemplo, si nuestra Master Page tiene un elemento de imagen llamado 'Logo' y
queremos variarlo en cada página mediante código sólo habría que escribir:
Master.FindControl("Logo")
Master.Logo = "http://www.microsoft.com/logo_msdn.gif"
que nos aislará de lo que ocurra debajo para gestionar ese logo.
Gracias a las Master Pages podemos definir una estructura común para las páginas de
nuestra aplicación Web. Sin embargo aún no hemos resuelto todas las cuestiones
sobre el mantenimiento de la interfaz que habíamos planteado. Los controles que
añadamos a las zonas de contenido de nuestras páginas todavía tendrán el aspecto
predeterminado. Podemos configurar su aspecto estableciendo las propiedades de
apariencia del control (como BackColor, Font, etc...). El problema que tiene este
método es que, si deseamos cambiar por completo la apariencia de estos controles,
tendríamos que tocar una por una todas las páginas. Esta no es una opción admisible
en cuanto la aplicación dispone de más de unas pocas páginas.
Veamos las opciones que nos ofrece ASP.NET 2.0 para solventar esta otra parte de un
mismo problema.
HTML ofrece una interesante opción para independizar el aspecto de sus elementos
del contenido de las páginas a través del uso de las hojas de estilo en cascada
(Cascading Style-Sheets o CSS). Las hojas CSS permiten definir el aspecto de
cualquier elemento HTML contenido en una página. Aunque se pueden definir dentro
de la propia página, hacerlo así les hace perder su verdadero sentido que no es otro
que el de separar la definición del aspecto. Así, es posible crear archivos con
extensión '.css' que se vinculan a las diferentes páginas de un sitio y definen el
aspecto de sus elementos.
a {
text-decoration: none;
color: #DBB94F;
}
body {
background-color: #656565;
background-image: url(Images/background.gif);
background-repeat: repeat;
margin: 0;
padding: 0;
text-align: center;
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 0.7em;
color: #FFFFFF;
}
En este fragmento, las etiquetas definen el aspecto que deben tomar los enlaces y el
cuerpo de la página.
· Clases: definen aspectos que no están asociados a una etiqueta HTML concreta
sino que se pueden asignar mediante el atributo class a cualquiera de ellas. Por
ejemplo:
EstiloSimple {
text-decoration: none;
color: #DBB94F;
}
.....
Para asignar un archivo CSS a una página sólo hay que incluir en su cabecera una
linea análoga a esta:
La gran ventaja de esta técnica es que basta con tocar el archivo CSS para que todas
las páginas que lo utilizan vean su aspecto modificado de manera acorde a los
cambios. Da igual que sea sólo una o haya miles. Al tener el aspecto centralizado en
una ubicación única el mantenimiento es muy sencillo.
Se puede añadir una etiqueta <LINK> a la cabecera de una página ASPX y los
elementos HTML que se generan a partir de los controles que contiene se mostrarán
siguiendo las indicaciones de la misma.
El entorno de desarrollo de Visual Studio permite definir los estilos de los controles
HTML de servidor de ASP.NET utilizando su propiedad Style, tanto en tiempo de
diseño como durante la ejecución. El diseñador de páginas ASPX incluso ofrece un
diálogo especializado para crear los estilos.
La funcionalidad ofrecida por los temas de ASP.NET 2.0 se entiende fácilmente si los
asemejamos con las hojas de estilo. Los temas de ASP.NET son como hojas de estilo
que se aplican a controles Web y sus elementos tienen una sintaxis prácticamente
idéntica a la de los controles cuyo aspecto definen. Enseguida lo entenderemos.
La carpeta App_Themes
Un tema de ASP.NET 2.0 está formado por uno o varios archivos de tipo .skin junto
con las imagenes y hojas de estilo CSS que éstos utilicen, que se almacenan dentro
de una carpeta con el nombre del tema dentro de una carpeta especial. Esta carpeta
de nombre especial es App_Themes.
Una vez creada la carpeta de temas deberemos crear un archivo .skin para comenzar
a definir con él nuestro primer tema. Para ello agregaremos un nuevo elemento. En el
diálogo que aparece seleccionaremos un archivo de máscara, como se muestra en la
figura:
conseguiremos que las páginas que lo apliquen dispongan de controles TextBox con el
fondo gris claro y el borde punteado de 1 pixel de ancho. Las rejillas que se utilicen
automáticamente tendrán el fondo blanco y las líneas pares azules.
TRUCO:
Dado que Visual Studio no proporciona asistencia para crear archivos de
máscara (es un simple editor de texto), una forma sencilla de definir sus
elementos es utilizar una página ASPX vacía para arrastrar y configurar
controles con los aspectos deseados. Luego sólo hay que copiar su
definición al archivo .skin eliminando todos los atributos ID.
Nota:
Los creadores de controles pueden emplear el atributo
ThemeableAttribute para indicar que una propiedad no es
personalizable mediante una máscara.
Asignación de temas
Ahora que ya conocemos la teoría acerca de los temas y sabemos crear archivos de
máscara para los temas vamos a aprender a utilizarlos en la práctica.
Dado que podemos disponer de varios temas se puede asignar uno diferente a cada
grupo de páginas de una aplicación según las necesidades.
Nota:
Lo más interesante de este atributo Theme es que se puede establecer
en cualquier momento. Es decir, podemos desarrollar una aplicación
completa sin pensar siquiera en los temas, y añadírselos sin demasiado
esfuerzo al final con sólo asignarlo. Ello permite además separar la labor
de diseño de la de desarrollo que incluso la puede hacer un equipo de
trabajo diferente.
Asignación global de temas
El uso del atributo Theme es muy adecuado cuando sólo tenemos unas pocas páginas
a las que aplicárselo. En aplicaciones grandes el hecho de tener que recorrer las
páginas una por una para asignarlo puede ser muy tedioso, con lo que perderíamos
bastante de la productividad ganada.
Para evitar esta situación ASP.NET ofrece otra forma de establecer los temas de forma
global. Consiste en añadir un nuevo nodo de tipo <pages theme=.../> al archivo de
configuración de la aplicación, el archivo web.config. La entrada sería similar a la
siguiente:
Al hacerlo todas las páginas de la aplicación utilizarán el tema indicado sin necesidad
de establecerlo manualmente.
Si se define un tema específico para una página, éste tendrá precedencia sobre el
ajuste de Web.config. De hecho si deseamos que una página no utilice tema alguno
sólo hay que establecer su atributo Theme a una cadena vacía ("").
Nota:
Dado que una aplicación Web puede disponer de varios archivos de
configuración (uno por cada carpeta) si queremos que la aplicación
emplee un tema diferente en diferentes zonas sólo tenemos que guardar
todas las páginas de cada zona en una carpeta diferente y crear archivos
web.config específicos para indicar el tema en cada una de ellas. Las
carpetas que no dispongan de su propio web.config heredarán el tema
principal del sitio.
Precedencia de propiedades
Cuando un elemento de una máscara define un atributo para un control, éste tiene
precedencia sobre el mismo atributo en caso de que se haya asignado también en la
página. Por ejemplo, si en una página tenemos un TextBox cuyo color de fondo lo
hemos establecido en amarillo, pero en el archivo .skin del tema que utiliza la página
este color indica que debe ser gris, al ejecutar la aplicaicón se verá de color gris.
Una forma alternativa de definir un tema para una página que cambia este orden de
precedencia es emplear el atributo StylesheetTheme en lugar del más común Theme
que hemos visto hasta ahora:
...
En este caso el valor establecido en la página para una propiedad tiene preferencia
sobre el valor del archivo de máscara en caso de haber coincidencia. Justo al contrario
que en el caso habitual.
En ocasiones es útil dejar un control con su aspecto habitual de forma que no se vea
afectado por el tema asignado a la página. La forma de conseguirlo es asignando su
propiedad EnableTheming a False.
Al igual que en el caso de las hojas de estilo en los temas se pueden definir distintas
clases de un mismo control, cada una con unos atributos específicos. La forma de
distinguir unos de otros es a través del atributo SkinID. Considere el siguiente
ejemplo:
En este caso se han definido tres clases de controles TextBox. Los dos primeros
tienen asignado un SkinID y sólo se aplicarán a aquellos controles TextBox cuya
propiedad SkinID coincida con el SkinID de la definición. La última definición no tiene
asignado identificador alguno por lo que se considera la clase por defecto y se aplicará
a todos los controles de texto que no hayan indicado específicamente un SkinID.
Lo habitual es separar los distintos grupos de controles es varios archivos .skin dentro
de la carpeta de un tema. Se reconocerán como si estuvieran todos en el mismo
archivo pero es más ordenado gestionarlos por separado.
Rutas de imágenes
Por supuesto en las propiedades de los elementos de una máscara se pueden utilizar
imágenes como en este ejemplo:
HTTP es un protocolo sin estado y como tal no existe forma a priori de distinguir entre
las diferentes peticiones realizadas a un servidor Web. Sin embargo las aplicaciones
Web necesitan mantener de algún modo un estado que les permita agrupar de
manera lógica las llamadas. Sin ello no habría forma, por ejemplo, de distinguir dos
llamadas a una misma página de dos usuarios diferentes. Para conseguir este artificio
sobre un protocolo sin estado ASP.NET proporciona las sesiones.
Nota:
Cabría pensar que una buena forma de distinguir unas llamadas de otras
en una aplicación Web es a través de la dirección IP del cliente. Nada
más lejos de la realidad. Dos usuarios diferentes que accedan detrás de
un mismo router (por ejemplo, dos personas en una misma oficina)
tienen la misma IP exactamente. Además, desde el punto de vista de la
seguridad es muy mala idea usar invariantes de este estilo pues son
fáciles de falsear.
Variables de sesión
ASP.NET ofrece una colección llamada Session en el objeto Page que nos permite
almacenar parejas de claves y valores que están disponibles desde todas las páginas
de una aplicación y se distinguen automáticamente para cada cliente que las utilice.
Esto implica que podremos almacenar valores de cualquier tipo a los que podremos
cuando sea necesario mientras el usaurio que solicite las páginas sea el mismo. Por
convención a las parejas de claves y valores almacenados en el objeto Session se les
denomina variables de sesión.
Por ejemplo, si quiero contar cuantas veces ha pasado un usuario por una página
'a.aspx' puedo escribir en su evento Load lo siguiente:
Session("Cuenta") += 1;
Esto haría que el valor asociado con la clave "Cuenta" se incrementara en uno cada
vez que se cargue la página. Es decir, en palabras llanas, incrementa en la unidad el
valor de la variable de sesión "Cuenta".
Response.Write(Session("Cuenta"))
Una cookie de sesión no es más que una cabecera HTTP con un identificador único
que el servidor envía al cliente en la primera petición que éste hace y que el
navegador se encarga de reenviar automáticamente en las sucesivas peticiones. Así,
basta con comprobar esta cabecera en el servidor en cada petición para averiguar qué
usuario es el que la realiza. Así de simple.
ASP.NET_SessionId=43s3ir55u0vvlj55smesaj45
El sistema de cookies de sesión descrito funciona muy bien en la mayor parte de los
casos pero tiene algunos inconvenientes, el principal de los cuales es que si el usuario
ha deshabilitado las cookies de sesión todo dejará de funcionar.
http://www.miservidor.com/miapp/pagina.aspx
http://www.miservidor.com/miapp/(S(1rhk5t45tlxy3e45swjibe55))/pagina
.aspx
Como vemos se introduce una última carpeta virtual con un identificador aleatorio y
cifrado (del estilo del que iba en las cabeceras HTTP). Esta carpeta obviamente no
existe pero uno de los gestores de la llamada a las páginas de ASP.NET es capaz de
distinguir que se trata de un identificador de sesión y actuar de manera transparente
para mantenerla y enviar las peticiones a las páginas correctas.
Este método es menos propenso a fallos que el anterior pero tiene el inconveniente de
que se generan URLs mucho más largas y menos atractivas. Las sesiones sin cookies
no existían en ASP 3.0.
Habilitar este tipo de sesiones es muy sencillo. Basta con abrir el archivo de
configuración de la aplicación (web.config) y añadir el siguiente ajuste dentro del
nodo <system.web>:
Almacenamiento de sesiones
Dado que cada máquina mantiene su propia copia de las sesiones, a menos que cada
usuario se redirija siempre al mismo servidor, no habrá forma de mantener una
sesión coherente, pues no existe una ubicación compartida para almacenar los datos
de las sesiones.
Nota:
Existe forma de configurar las granjas de servidores con afinidad de
manera que cada usuario siempre se redirija al mismo servidor. Aún así
existen otros problemas con la sincronización de datos compartidos en
toda la aplciación y además el sistema reduce la escalabilidad.
Nota:
Gracias al modelo de extensibilidad mediante proveedores que ofrece
ASP.NET 2.0 es posible escribir nuestros propios proveedores para
almacenar la sesión del modo que más nos convenga, si bien no es lo
habitual. Esta característica incluso nos permite definir un formato
propio para los identificadores de sesión aunque hacerlo no es en
general una buena idea.
<sessionState timeout="10"/>
También se puede asignar mediante cádigo usando la propiedad Timeout del objeto
Session.
Session.Timeout = 10
Session.Abandon()
En ASP 3.0 estaba limitado el tipo de objetos que podíamos almacenar en variables de
sesión. Por ejemplo, no se debían almacenar objetos RecordSet de datos o perdíamos
escalabilidad, y había otros tipos de objetos que generaban un error al intentar
almacenarlos. El uso directo de ciertos objetos como las matrices desde variables de
sesión penalizaba el rendimiento.
En el caso de ASP.NET no existen estas limitaciones y podemos almacenar cualqueir
objeto .NET sin problema cuando usamos el modelo en memoria. En el caso de los
modelos de almacenamiento centralizado los objetos a almacenar deben ser
serializables.
Variables de aplicación
Application("Contador") += 1
Esta variable estará accesible desde cualquier otra página de cualquier sesión de
usuario.
El código anterior presenta un problema poco evidente que tiene que ver con la
concurrencia de uso de las variables de aplicación. En una aplicación Web pueden
estar ejecutándose al mismo tiempo varias páginas. De hecho es bastante probable
que existan muchas coincidencias a la hora de escribir en la variable anterior si
metemos ese código en todas las páginas de una aplicación y hay bastantes usuarios.
Ello provocaría inconsistencias en los valores y, a la larga, que el contenido de la
variable no contuviera el verdadero número de peticiones realizadas.
Para evitar estos problemas de concurrencia se definen dos métodos del objeto
HttpApplication que permiten el acceso en exclusiva a las variables de sesión por
parte de una página. La forma correcta del código anterior sería:
Application.Lock()
Application("Contador") += 1
Application.UnLock()
De este modo se bloquea el acceso de las demás páginas a las variables de aplicación
mientras no se llame al método de desbloqueo y se evitan así los problemas de
concurrencia. Hay que tener cuidado sin embargo con el uso que se hace de esta
característica pues puede afectar a la escalabilidad por bloqueos en las otras páginas.
Nota:
En ASP 3.0 esta era la única manera de compartir memoria en el ámbito
de aplicación, pero no está exenta de problemas. En ASP.NET se soporta
un método mucho mejor a través de objetos de caché que ahora
veremos y se desaconseja el uso de las variables de aplicación en la
medida de lo posible.
Almacenamiento en caché
Cache("MiClave") = miValor
....
Response.Write( Cache("MiClave") )
La caché se usa habitualmente para almacenar datos que son costosos de obtener y
que pueden ser aprovechados por todos los usuarios, como por ejemplo un DataSet
resultante de una compleja consulta a una base de datos.
Conseguirlo con la caché de ASP.NET es muy sencillo, basta con escribir la siguiente
línea:
Cache.Insert("MisDatos", datos,
New CacheDependency(Server.MapPath("misdatos.xml")))
Esta línea agrega el elemento sin dependencia en objeto alguno y con una fecha de
caducidad para dentro de dos horas.
En este caso la caducidad es relativa e indica que el valor caducará en cuanto nadie
haga uso de el durante 30 minutos.
La caché de salida de ASP.NET es un mecanismo que nos permite decidir qué partes
de una página deben generarse en cada solicitud y cuáles pueden ser aprovechadas
para posteriores peticiones. Su uso es extremadamente sencillo y pueden aumentar
de forma espectacular el rendimiento de cualquier aplicación.
Como se pueden aplicar las directivas de caché de salida a los controles de usuario, si
necesitamos hace caché sólo de determinadas partes de una página y no de la página
entera, podemos convertir éstas en controles de usuario y conseguir el efecto
buscado.
Directiva OutputCache
Para poder hacer caché del contenido de una página o un control de usuario hay que
indicar a ASP.NET de qué depende la caducidad de dicho contenido. Para ello se utiliza
la directiva OutpuCache.
La caducidad puede depender del tiempo, de algún parámetro, de una cabecera, etc...
En páginas que, por ejemplo, visualizan muchos resultados obtenidos de una base de
datos y que varían con poca frecuencia puede aumentar muchísimo el rendimiento.
Atributos de OutputCache
· VaryByParam: permite especificar que se haga una caché por cada valor
diferente que tome un parámetro que se le pasa a la página y que se indica en
este atributo. Por ejemplo, si tenemos una página a la que se le pasa un
parámetro "pais" y que devuelve un listado de clientes en dicho país, al indicar
VarByparam="Pais" conseguiremos una caché de resultados diferente para cada
valor del parámetro. Cuando se le pasa un nuevo valor se ejecuta la página y se
almacena el resultado para las restantes veces que se solicite con el mismo
parámetro (durante el tiempo especificado). Si hay más de un parámetro se
pueden especificar separándolos por punto y coma.
· VaryByHeader: guarda una caché para cada valor de la cabecera HTTP
indicada. Por ejemplo si se indica varByHeader="User-Agent" conseguiremos
una versión en caché de la página por cada tipo de navegador utilizado para
acceder a la página. Se pueden especificar varias cabeceras separándolas por
punto y coma.
· VaryByControl: en el caso de controles de usuario su caché se fragmentará
por cada valor de las propiedades del control indicadas en el atributo. No es
válido en directivas de página, sólo de controles de usuario y se debe
especificar siempre el VarByparam aunque sea con valor "None".
· VaryByCustom: permite implementar nuestro propio criterio de caché. Se
debe implementar la función global GetVaryByCustomString (dentro de
Global.asax) a la cual se le pasa el valor del atributo para que pueda decidir
cómo actuar. No vamos a entrar en más detalles en este curso.
Almacenamiento en disco
Sustitución post-caché
ASP.NET 2.0 ofrece multitud de novedades en este aspecto que nos van a simplificar
mucho el trabajo.
Autenticación IIS/Windows
No vamos a profundizar en este aspecto pues se sale del ámbito del curso, pero baste
decir que, para sitios Web grandes accesibles desde Internet la autenticación de IIS
(que se basa en usuarios de Windows) no es la más habitual porque se necesitaría
una licencia de acceso or cada usuario con nombre. ASP.NET ofrece un gran soporte
para trabajar con los usuarios una vez autenticados con el sistema,
fundamentalmente para averiguar si pertenecen a un determinado perfil de usuario,
incluso en entornos de seguridad centralizada con Directorio Activo.
El funcionamiento es el siguiente:
Figura 5.10.- Lógica de autenticación personalizada en ASP.NET
Nota:
El uso de cookies era obligatorio en ASP.NET 1.x para utilizar la
autenticación Forms. ASP.NET 2.0 soporta la autenticación sin cookies de
un modo muy similar al que hemos visto para sesiones sin cookies:
introduciendo una ruta virtual codificada en todas las peticiones. Sólo
hay que utilizar el ajuste <forms cookieless="UseUri"> en el archivo de
configuración.
<authentication mode="Forms"/>
Por defecto la página a la que se redirige a los usuarios anónimos para que se
autentiquen se llama "login.aspx" pero se puede especificar cualquier otra usando el
atributo loginUrl, por ejemplo:
<authentication mode="Forms">
<forms loginUrl="entrada.aspx"/>
</authentication>
Una vez que un usuario está autenticado, el proceso que regula a qué recursos tendrá
acceso se denomina autorización.
Para realizar el control de acceso no sólo llega con indicar qué método de
autenticación se usará (en este caso Forms) . Además hay que especificar a qué
recursos se debe controlar el acceso y de qué manera. En ASP.NET existen diversos
modos de definir la autorización de acceso.
Autorización de URLs
<location path=“facturas.aspx”>
<system.web>
<authorization>
</authorization>
</system.web>
</location>
- El nodo location especifica la ruta relativa al directorio actual cuyo acceso se desea
controlar.
Pueden incluirse tantos nodos location como sea necesario dentro del archivo de
configuración.
<authentication mode="Forms"/>
<authorization>
<deny users="?"/>
</authorization>
Dado que puede existir un archivo web.config por cada carpeta de la aplicación se
pueden establecer distintos criterios de acceso a cada una, agrupando en ellas los
archivos con el mismo nivel de acceso.
Autorización declarativa
El sistema de autorización por URL es muy potente pues permite definir los permisos
de acceso de los usuarios a cualquier archivo controlado por ASP.NET y además
hacerlo sin tocar el código. Mediante la autorización declarativa de ASP.NET es
posible obtener un control mucho más granular, llegando incluso a controlar accesos a
clases o métodos concretos dentro de éstas. Es decir, regula la autorización dentro
del código de la aplicación, definiendo a qué partes de éste se debe conceder el
acceso y cómo.
Mediante simples atributos se controla el acceso a cada método o propiedad de una
clase o a la clase misma:
<PrincipalPermission(SecurityAction.Demand, Authenticated:=true)> _
Class CuentaBancaria
<PrincipalPermission(SecurityAction.Demand, Role:=“Cajero")> _
Public Function Consultar() As Integer
...
End Function
<PrincipalPermission(SecurityAction.Demand,
Role:="Interventor")> _
Public Sub ModificarSaldo()
...
End Sub
End Class
Autorización imperativa
End if
End If
End Sub
La principal ventaja de esta forma de autorización es el fino control que concede. Sin
embargo conviene no abusar de su uso en la medida de lo posible ya que cualquier
cambio implica tocar el código convirtiéndolo enseguida en muy dificil de mantener.
La nuevas API: Membership y Roles
Todo lo mencionado hasta ahora esmuy interesante pero todavía carece de lo más
importante: ¿cómo autenticamos a los usuarios? ¿Cómo sabemos a qué roles
pertenecen?
Hasta ahora estas preguntas las debía contestar el propio programador ya que en
ASP.NET 1.x era su responsabilidad definir los métodos de autenticación de sus
aplicaciones. Ello implicaba normalmente escribir código de consulta contra bases de
datos que validase las credenciales de los usuarios y obtuviese los roles de los
mismos. Luego se creaban objetos de seguridad asignándole estos valores y
asociándolos al contexto de la aplicación.
ASP.NET 2.0 nos libera por fin de todo ello y ofrece de serie una completa API de
gestión de usuarios que nos evita tener que reinventar la rueda en cada aplicación.
Membership
Se trata de una nueva API que proporciona una sencilla interfaz de programación para
almacenar y recuperar información sobre los usuarios de nuestras aplicaciones. Lo
más interesante de todo es que, al igual muchas otras características nuevas de
ASP.NET 2.0, está basado en un patrón de diseño de proveedores, lo que permite
cambiar los métodos de trabajo y almacenamiento sin tocar el código de la aplicación.
La figura siguiente ilustra mejor este concepto:
Figura 5.11.- Patrón de Proveedores para gestión de usuarios
Por defecto esta API utiliza SQL Server 2005 para almacenar toda la información de
seguridad de una aplicación y va a ser lo que utilicemos durante toda esta lección.
Pero dada su arquitectura basada en proveedores podemos cambiar el modo de
gestión con sólo un ajuste en el archivo de configuración. incluso, como se ve aprecia
en la figura, es posible definir métodos de gestión de usuarios propios sin modificar el
código de nuestras aplicaciones. Esto nos permite reutilizar infraestructuras de
seguridad preexistentes que hubiésemos creado para ASP.NET 1.x sin perder el
trabajo.
Membership consta de una clase con este nombre que contiene ciertos métodos
compartidos para poder crear, eliminar y validar usuarios entre otras cosas. Así, por
ejemplo, para crear un usuario escribiríamos:
Membership.CreateUser("usuario", "clave")
Membership.ValidateUser("usuario", "clave")
Roles
Esta API complementa a la anterior para permitir la gestión de los roles de un usuario
y, al igual que ésta, está basada en el mismo patrón de proveedores. No es necesario
utilizar el mismo proveedor para los roles que para los usuarios. Por ejemplo, se
pueden autenticar usuarios contra una base de datos SQL Server y obtener los roles
desde el Directorio Activo o las cuentas locales.
Al igual que en el caso anterior los métodos de la clase Roles son todos estáticos y
podemos usarlos sin instanciar nuevos objetos. Por ejemplo:
Roles.AdduserToRole("usuario", "administradores")
Este fragmento agrega un usuario al rol de administradores. Para obtener los roles a
los que pertenece un usuario podemos escribir:
Roles.getRolesforuser("usuario")
Con todo lo visto hasta ahora crear la seguridad de un sitio web es muy sencillo. Sólo
hay que establecer la autenticación Forms de ASP.NET y utilizar Membership y Roles
para gestionar a los usuarios.
Aún así todavía queda trabajo. Hay que crear formularios de autenticación y, antes de
nada, hay que gestionar los usuarios y los roles de la aplicación.
ASP.NET 2.0 tampoco nos va a dejar solos con esto. Ofrece una completa herramienta
de administración ya creada de serie y, como veremos enseguida, ni siquiera nos
obliga a crear interfaces comunes de autenticación y gestión de sesiones.
Antes de nada hay que administrar usuarios y roles. Para ello sólo tenemos que
presionar sobre el menú Sitio web·Configuración de ASP.NET y se abrirá una web que
nos permite configurar la seguridad de la aplicación.
Figura 5.12.- Sitio de configuración de la seguridad de ASP.NET 2.0
Nota:
Si hace uso de esta herramienta para crear usuarios en la base de datos
tenga en cuenta que por defecto hay un ajuste de seguridad que implica
el uso de claves complejas. Cualquier clave que introduzca le devolverá
el enigmático mensaje "Introduzca otra contraseña" a menos que use
claves de al menos 7 caracteres de longitud e incluya en ellas un espacio
o un caracter no alfanumético como un asterisco o un guión bajo. Este
ajuste se puede cambiar mediante configuración.
El administrador de sitios Web utiliza las clases MemberShip y Roles para realizar su
trabajo. Disponemos de su código fuente completo en la carpeta
C:\WINDOWS\Microsoft.NET\Framework\v2.0.xxxxx\ASP.NETWebAdminFiles\ y es
interesante examinarlo.
El control Login
El control LoginStatus
Se puede personalizar por completo para mostrar cualquier otra cosa en la superficie
del control.
El control LoginName
El control LoginView
La primera de las acciones, Editar RoleGroups, permite definir los casos que
existirán en función de los roles. Por ejemplo si queremos mostrar un mesnaje
diferente según sea un usuario anónimo, un usuario autenticado en general y un
usuario que pertenece al rol de administradores, tendríamos que añadir un RoleGroup
con el texto "Administradores" ya que los otros dos casos siempre están definidospor
defecto.
Al igual que los anteriores ofrecen una altísima capacidad de personalziación que en el
caso del control de creación de usuarios permite incluso añadir nuevos pasos en el
asistente (se trata de un control heredado del control de tipo Wizard que nos permite
crear asistentes con facilidad).
Todos ellos utilizan la API de Membership para trabajar y responden a los ajustes
impuestos en la configuración de la aplicación. Así pues, por ejemplo, el control de
cambio de contraseña o el de creación de usuarios exigirán a las contraseñas la
complejidad indicada en la configuración, y el de recuperación de clave le hará una
pregunta de seguridad si así está definido.
Tras una introducción a los servicios Web y sus conceptos asociados se ve la forma de
crear y consumir servicios Web desde ASP.NET 2.0 usando Visual Studio 2005.
La expresión "Servicio Web" se oye con fuerza desde hace unos años en el ámbito del
desarrollo de aplicaciones e incluso en ambientes poco técnicos y de dirección. Lo
cierto es que no se trata de un concepto tan novedoso como cabría esperar y las
innovaciones que conlleva no son tanto tecnológicas, como conceptuales.
Estos programas podían acceder a un sistema gestor de datos a través de la red, pero
toda la lógica del flujo de datos, la seguridad y las interacciones con las personas se
encontraban en el ordenador del usuario en forma de un gran ejecutable. Se suelen
conocer también como "fat clients". La situación descrita no es la ideal ya que implica
problemas de toda índole a la hora de instalar las aplicaciones y sobre todo cuando se
modifican o actualizan (mantenimiento complejo y engorroso).
La belleza de este modelo radica en que cada uno de ellos (o cada grupo de ellos)
puede residir en un servidor diferente, siendo transparente su ubicación para los
clientes que los utilizan. Ello aumenta mucho la escalabilidad de las aplicaciones, pues
basta con añadir nuevos servidores e instalar los componentes en ellos para poder
atender más peticiones.
Por otra parte, y esto es muy interesante también, mientras sus interfaces de
programación sean las mismas, es posible sustituir cualquier componente por otro
actualizado o que actúe de manera distinta para corregir errores o cambiar el modo
de trabajo de la aplicación global, y todo ello sin que los clientes sean conscientes de
ello. Obviamente esto ofrece más ventajas aún ya que, por ejemplo, no es necesario
reinstalar la aplicación en cada cliente, sino que basta con sustituir un componente en
un único lugar y automáticamente todos los usuarios tendrán su aplicación
actualizada.
Aunque muchos programadores piensan que SOA está relacionado únicamente con los
Servicios Web lo cierto es que se pueden conseguir arquitecturas SOA con otras
tecnologías como veremos.
Comunicación entre componentes
Estos modelos son buenos y muy eficientes, cumpliendo bien su trabajo pero tienen
algunas limitaciones importantes siendo las principales las siguientes:
Las expectativas actuales respecto a los componentes han aumentado. Al igual que
podemos usar un navegador web para acceder a cualquier página
independientemente del sistema operativo del servidor en que resida, ¿por qué no
podríamos invocar métodos de componentes a través de la red independientemente
de dónde se encuentren, del lenguaje en el que estén escritos y de la plataforma de
computación en la que se ejecuten?.
Esto es precisamente lo que ofrecen los Servicios Web. Gracias a ellos se derriban la
antiguas divisiones resultantes de los modelos de componentes descritos, y la
integración de las aplicaciones, la ubicuidad de sus componentes y su reutilización a
través de la red se convierten en una realidad.
La tecnología que está detrás de todo ello se llama SOAP (jabón en inglés). Este
acrónimo (Simple Object Access Protocol) describe un concepto tecnológico basado en
la sencillez y la flexibilidad que hace uso de tecnologías y estándares comunes
para conseguir las promesas de la ubicuidad de los servicios, la transparencia de los
datos y la independencia de la plataforma que según hemos visto, se hacen
necesarios en las aplicaciones actuales.
SOAP empezó como un protocolo de invocación remota basado en XML diseñado por
Dave Winer de UserLand, llamado XML-RPC. A partir de éste se obtuvo en Septiembre
de 1999 la versión 1.0 de SOAP, en la que participo activamente Microsoft y el
archiconocido experto en programación Don Box.
Esta primera versión fue más o menos despreciada por los principales fabricantes de
software que en esa época tenían en marcha un proyecto más ambicioso llamado
ebXML. Esto puso en peligro en su nacimiento la existencia de SOAP ya que si los
grandes no lo apoyaban poco se podía hacer. Por fortuna uno de estos grandes
fabricantes, IBM, decidió apoyarlo y en la actualidad no sólo acepta SOAP sino que es
uno de lo motores detrás de su desarrollo (dos importantes personas de IBM y su filial
Lotus, David Ehnebuske y Noah Mendelsohn, son autores de la especificación 1.1 de
SOAP). Sun Microsystems también anunció oficialmente en Junio de 2000 que
soportaba el estándar. El hecho de que los tres gigantes del software (Microsoft, IBM
y Sun) apoyen SOAP ha hecho que muchos fabricantes de Middleware y puentes
CORBA-DCOM (como Roguewave o IONA) ofrezcan productos para SOAP, así como
otras muchas pequeñas empresas de software.
El paso definitivo para asegurar el éxito de SOAP y los servicios web es su envío al
W3C (World Wide Web Consortium) para proponerlo como estándar. La última versión
de la especificación se puede encontrar en www.w3.org/TR/SOAP/.
Este soporte mayoritario hace que su éxito y pervivencia estén asegurados y hoy
todas las herramientas de desarrollo del mercado ofrecen en menor o mayor medida
soporte para SOAP. Por supuesto .NET y Visual Studio son los entornos más
avanzados en la adopción de SOAP.
· Dado que los mensajes entre componentes y los datos de los parámetros para
llamadas a métodos remotos se envían en formato XML basado en texto plano,
SOAP se puede utilizar para comunicarse con cualquier plataforma de
computación, consiguiendo la ansiada ubicuidad de los componentes.
· El uso de HTTP como protocolo principal de comunicación hace que cualquier
servidor web del mercado pueda actuar como servidor SOAP, reduciendo la
cantidad de software a desarrollar y haciendo la tecnología disponible
inmediatamente. Además en la mayoría de los casos se puede hacer uso de
SOAP a través de los cortafuegos que defienden las redes, ya que no suelen
tener bloqueadas las peticiones a través del puerto 80, el puerto por defecto de
HTTP (de ahí la ubicuidad, aunque se pueden usar otros puertos distintos al 80,
por supuesto).
Por otra parte la escalabilidad se obtiene a través del propio servidor web o incluso
del sistema operativo, ya que la mayoría de ellos (por ejemplo IIS) poseen
capacidades de ampliación mediante clusters de servidores, enrutadores que
discriminan las peticiones y otras técnicas para crear Web Farms, o conjuntos de
servidores web que trabajan como si fueran uno solo para así poder atender a más
clientes simultáneamente.
Nota:
Existen ampliaciones al protocolo SOAP base que definen protocolos y
convenciones para tareas específicas como las mecionadas de seguridad,
enrutado de mensajes, los eventos y muchas otras cuestiones
avanzadas. En .NET se implementan mediante los concidos Web Services
Enhancements (WSE) actualmente por su versión 3.0, y en un futuro
inmediato con Windows Communication Foundation, la nueva plataforma
de servicios de comunicaciones de Windows. El estudio de éstos se sale
del ámbito de este curso.
Otro de los estándares que se definen en SOAP es WSDL (Web Service Definition
Language). Se trata de un formato estándar para describir las interfaces de los
servicios web. WSDL describe qué métodos están disponibles a través de un servicio
Web y cuáles son los parámetros y valores devueltos por éstos. Antes de usar un
componente que actúa como servicio web se debe leer su archivo WSDL para
averiguar cómo utilizarlo.
Nota:
Para aquellos programadores que conocen otras arquitecturas podemos
decir que WSDL es el equivalente en XML a los lenguajes IDL (Interface
Description Language) de DCOM y CORBA.
En el módulo anterior se presentaron los servicios web: qué son, de dónde vienen y a
dónde van. Tras la teoría veremos una sencilla aplicación práctica construyendo, paso
a paso, un servicio web con Visual Studio 2005, y comprobaremos lo extremadamente
simple que es su creación con esta herramienta.
Nuestro primer ejemplo será un servicio web muy simple que se ocupará de devolver
la fecha y la hora actuales del servidor en el que se ejecute.
Para crear un nuevo proyecto que albergue servicios Web sólo tenemos que utilizar el
menú Archivo·Nuevo sitio Web y elegir el tipo "Servicio Web" en lugar del habitual
"Sitio web ASP.NET" tal y como se muestra en la figura:
Figura 6.4.- Nuevo proyecto de servicios Web
Nota:
En realidad tampoco es necesario puesto que se pueden crear archivos
de servicios web dentro de proyectos de aplicaciones Web "normales"
usando el diálogo Agregar nuevo elemento. Sin embargo, lo habitual es
que se guarden en proyectos separados para facilitar su posterior
gestión.
Ésta se parece mucho a la directiva de las páginas ASPX y, al igual que en ese caso,
define dónde se encuentra en código que dotará de funcionalidad al servicio Web. En
este caso y dado que el servicio Web no posee elementos de interfaz de usuario, del
único archivo que nos tenemos que preocupar es del que se indica en el atributo
CodeBehind. Éste contiene la definición de la clase indicada en el atributo Class, y que
en nuestro ejemplo se llama Service.
La clase Service (podría llamarse de cualquier otro modo) está dentro del archivo
Service.vb, el cual se ubica dentro de la carpeta App_Code que como ya hemos
estudiado asegura la compilación dinámica de los archivos de código que contiene.
Aparte de las preceptivas sentencias Imports, vemos que la clase Service hereda de la
clase WebService. Sólo con hacer esto ya obtenemos la funcionalidad necesaria para
gestionar el XML, HTTP y demás tecnologías en las que se basan los servicios Web. su
gestión pasa inadvertida para nosotros.
Los métodos que un servicio Web expone al exterior son métodos normales de una
clase a los que se le ha añadido el atributo WebMethod, tal y como se observa en el
código anterior. Es decir, para que uno de nuestros métodos sea expuesto en un
servicio Web y pueda ser utilizado remotamente desde cualquier otra plataforma o
lenguaje basta con incluir el atributo WebMethod delante y que esté contenido dentro
de una clase que hereda de WebService. Así de sencillo.
Por ejemplo, elimine el método de ejemplo HelloWorld que introduce Visual Studio y
escriba el siguiente código:
Ahora disponemos de un método que devuelve la fecha y la hora actuales en el
servidor en el que se ejecute nuestro servicio Web y que puede ser utilizado desde
cualquier otra aplicación independientemente del lenguaje con el que esté construida
y del sistema operativo en el que trabaje. Enseguida veremos cómo.
Este ejemplo, aunque trivial, puede resultar útil en entornos, como los de gestión, en
los que la sincronización horaria entre clientes y servidores es fundamental para
asegurar la coherencia de facturaciones y otros datos económicos.
Tipos de datos
Vamos a mejorar un poco el ejemplo. Tratar una fecha a partir de una cadena es un
poco tedioso porque hay que analizarla para obtener sus diversas partes (día, mes,
año, hora, minutos y segundos) y además su formato depende del idioma definido en
el servidor, que no tiene porque ser el mismo que tienen los clientes. Lo ideal sería
obtener una representación única de una fecha sin preocuparnos de estos problemas.
Al igual que hemos definido como tipo devuelto una cadena podemos definir
perfectamente una fecha, quedando el código así:
Lo único que hemos cambiado es el tipo a devolver, pero hemos ganado mucho ya
que éste se interpretará correctamente como una fecha en cualquier aplicación que
consuma nuestro servicio.
Nota:
Los objetos de la clase DataSet de ADO.NET son objetos serializables
que están adaptados a la perfección para su uso en un servicio Web. De
hecho es muy habitual que se utilicen como valores devueltos y como
parámetros en métodos de servicios Web. Los DataSet tipados también
se incluyen en esta categoría y de hecho pueden resultar incluso más
sencillos de utilizar cuando el servicio se invoca desde entornos
diferentes a .NET.
Descripción de métodos
Con esto queda definido nuestro sencillo servicio web de ejemplo. Enseguida veremos
cómo utilizarlo.
Imaginemos que tenemos que crear un servicio Web para una tarea determinada
(para simplificar, digamos, realizar una suma), y dicha tarea debe trabajar con
diferentes tipos de datos o debe poder usarse de varias formas con parámetros
diferentes.
En una clase .NET podemos crear versiones sobrecargadas de un método cada una de
las cuales tomará el tipo de datos pertinente, siendo el propio compilador el que
llamará a la versión sobrecargada que convenga en cada caso.
MessageName se utiliza para asignar alias a los métodos Web que definamos, de
forma que podemos identificar de manera única a cada uno de ellos, incluso aunque el
nombre asignado a la función sea el mismo. De este modo, si queremos exponer
como servicio Web una clase que posee un método con varias sobrecargas sólo
tenemos que emplear este atributo asignándole un identificador diferente a cada una.
Por ejemplo:
Las dos funciones con el mismo nombre y diferentes parámetros son perfectamente
válidas en VB.NET. Sin embargo si hubiésemos colocado simplemente la palabra
WebMethod delante de ambas hubiésemos obtenido un error a la hora de compilar ya
que no pueden exponerse dos métodos con el mismo nombre en un servicio Web.
Cambiando el nombre del mensaje de una de ellas se pueden exponer sin problema
ya que a la hora de consumirlas, aunque tengan el mismo nombre, se distinguen
perfectamente por el nombre del mensaje empleado.
En esta lección vamos a estudiar el comportamiento del servicio Web que hemos
creado y aprenderemos a consumirlo desde una página ASP.NET además de a
examinarlos manualmente.
Este código XML es el que se utiliza para averiguar los métodos disponibles y como
invocarlos. Como es bastante tedioso leerlo, ASP.NET simplemente lo procesa por
nosotros y genera una bonita página Web para informarnos del contenido del servicio
de una forma más agradable para los humanos.
Lo interesante de esta página es que nos permite probar manualmente los métodos
del servicio Web siempre y cuando utilicen parámetros y valores devueltos sencillos.
Nota:
Esta página autogenerada sólo se muestra si se accede al servicio Web
en modo local. Si se intenta el acceso desde un equipo remoto no se
tendrá acceso por cuestiones de seguridad, aunque es posible habilitarlo
en casos que se haga necesario (para depuración remota, por ejemplo).
Sin embargo el WSDL (ruta al servicio Web seguido de ?WSDL) sí es
accesible siempre ya que es necesario que otras máquinas lo puedan
leer para hacer uso del servicio.
Cualquier cliente de SOAP sabe interpretar este valor como una fecha y por lo tanto
acceder a sus elementos es una tarea muy sencilla pues se convierte, en el caso de
.NET, en un objeto DateTime normal y corriente tras llamar a la función remota.
Cree un nuevo proyecto de aplicación Web y en la página Web por defecto agregue
una etiqueta Label1. Este etiqueta la usaremos para mostrar la hora en el servidor
obtenida mediante el uso del servicio Web creado en el apartado anterior.
Para poder hacer uso del servicio Web debemos añadir una referencia al mismo desde
nuestro proyecto. Esto se consigue presionando con el botón secundario sobre el nodo
del proyecto en el Explorador de soluciones y eligiendo la opción Agregar referencia
Web:
Figura 6.8.- Agregar referencia web
Al hacer esto se abre un diálogo que nos permite escribir la dirección del WSDL de
algún servicio Web concreto (si nos la sabemos) o buscar servicios Web en diversos
lugares.
Podemos buscar servicios en la misma solución de Visual Studio, buscar todos los
servicios que haya instalados en la máquina local o examinar directorios UDDI para
conocer los servicios que contienen.
En nuestro caso agregaremos una referencia al servicio Web de hora que creamos en
el apartado anterior escribiendo la URL en la línea de dirección URL.
Es decir, si alguien añade la referencia Web por nosotros y no nos dice que estamos
usando un servicio Web desde nuestro código no habrá diferencia a la hora de usar
los objetos expuestos a través del servicio, si bien éstos pueden estar ejecutándose
en otro servidor e incluso en otro país a través de Internet.
Nota:
Hacer uso de este servicio Web desde una aplicación Windows es igual
de fácil que desde una página ASP.NET. También podemos permitir que
programadores de otras plataformas hagan uso de nuestro servicio.
La propiedad Url de la clase proxy que se crea para acceder al servicio web nos
permite establecer en tiempo de ejecución la dirección en la que está ubicado el
WSDL del servicio que realmente usaremos. Éste obviamente debe ser idéntico (su
WSDL debe ser idéntica) al servicio web original que usamos en el desarrollo.
sh.Url = "http://www.serviciosweb.com/servicioHora.asmx"
....
....
....
Con esto obtendremos una barrera de protección básica para nuestro servicio Web.
Nota:
Existen una serie de especificaciones adicionales para servicios Web
denominadas Web Service Enhancenments (WSE) que añaden funciones
especiales para autenticación, privacidad, cifrado, enrutado, y otras
muchas tareas avanzadas. Estos WSE siguen las especificaciones
conocidas como WS-*, que son un estándar de la W3C y la nuev
aplataforma unificada de mensajería de Microsoft, Windows
Communication Foundation, también las implementa para sus
servicios web. El estudio de WSE se sale del ámbito de este curso.
A continuación vamos a desarrollar una aplicación que nos permita explorar las
principales características de Visual Studio 2005. Puede descargar el código fuente en
su máquina y explorarlo o modificarlo para conocer de forma práctica cómo usar
ASP.NET para desarrollar aplicaciones reales. También puede explorar los videos
donde construimos esta
aplicación paso a paso.
La aplicación
Nota:
MSDN Video utiliza una base de datos para almacenar su estado. Si
desea ejecutar la aplicación en su máquina necesitará SQL Server 2005
Express instalado.
Videos explicativos
Si desea ver cómo se hizo esta aplicación puede visionar estos videos donde
desarrollamos la aplicación paso a paso:
· Video 1. Introducción MSDN Video Web y Modelo de Datos
· Video 2. El Esqueleto de Presentación MSDN Video Web
· Video 3. Entidades de Negocio y Acceso a Datos de MSDN Video Web
· Video 4. Funcionalidad y Enlace de Datos de MSDN Video Web
· Video 5. Seguridad en MSDN Video Web
· Video 6. Transacciones, Temas y Pieles y Conclusión de MSDN Video Web
Tomado de:
http://www.desarrollaconmsdn.com/msdn/Cursos/Curso_Desarrollo_web_con_Visual_Stud
io_2005/index.html