Manual VWD 2005

Jos Manuel Alarcn Agun
PRESENTACIN
Este libro se ha concebido como una primera gua hacia el desarrollo Web para todos aquellos programadores
que se inician en este mbito con la versin 2005 de las herramientas de desarrollo de Microsoft.
El manual les resultar de inters tanto a los programadores que se acercan por vez primera a .NET como a
los que ya tienen experiencia con versiones anteriores del entorno. Los primeros encontrarn las pistas que
necesitan para comprender el funcionamiento del entorno y de las aplicaciones creadas con ste. Los
experimentados aprendern las novedades ms importantes que la versin 2005 tiene para ofrecerles,
comprobando la cantidad de mejoras que se han aadido y aprendiendo a utilizarlas.
Al terminar el libro sabr todo lo necesario para crear sus propias aplicaciones Web orientadas a datos y con
multitud de caractersticas avanzadas. Este manual le enseara entre otras cosas:
Cmo crear aplicaciones web con Visual Web Developer 2005 Express Edition
A utilizar controles web y controles HTML
Los mtodos bsicos de acceso a base de datos.
Los controles enlazados a datos.
A manejar las sesiones desde ASP.NET.
El modo de crear aplicaciones con un interfaz de usuario consistente y fcil de personalizar.
Control de acceso de usuarios.
Cmo exponer funcionalidad a otras aplicaciones mediante servicios Web.
Acerca del autor

Jose Alarcn Agun
ASP/ASP.NET MVP
Jos Manuel es ingeniero superior industrial y especialista universitario en consultora de
empresa. Es autor de varios libros, habiendo publicado hasta la fecha cerca de 300
artculos sobre informtica e ingeniera en publicaciones especializadas. Es colaborador
habitual de MSDN y de las ms importantes revistas del sector como PC World,
dotnetMania o Windows TI Magazine.
En la actualidad es socio de Grupo Femxa, "soluciones al servicio del

conocimiento", siendo tambin su responsable tcnico. A travs de Krasis
[www.krasis.com], la empresa tecnolgica del grupo, dirige para sus diferentes
clientes proyectos y productos orientados a la comunicacin, la mejora de procesos
y los sistemas de teleformacin.
Puede usted visitar su Blog sobre tecnologa .NET en www.jasoft.org.
2005 i
NDICE
CAPTULO 1.- INTRODUCCIN A LA PLATAFORMA .NET 1
1.1.- El entorno de ejecucin CLR 1
1.2.- El lenguaje intermedio y el CLS 1
1.3.- Cmo se consigue esta potente capacidad? 1
1.4.- La especificacin comn de los lenguajes y el sistema de tipos 2
comunes
1.5.- La biblioteca de clases de .NET 3
1.6.- Los espacios de nombres 4
1.7.- Acceso a datos con ADO.NET 4
1.8.- Arquitectura de ADO.NET 5
1.8.1.- Capa conectada 6
1.8.2.- Capa desconectada 6
1.9.- Aplicaciones Windows Forms 7
1.10.- Aplicaciones Web Forms 8
CAPTULO 2.- FUNDAMENTOS DEL DESARROLLO DE APLICACIONES WEB 11

2.1.- Las pginas ASPX 11
2.1.1.- Ms cdigo 12
2.1.2.- Estupendo, pero.. en qu hemos mejorado? 12
2.2.- El entorno de desarrollo: VWD Express 2005 13
2.2.1.- Explorando el entorno 13
2.2.2.- Explorador de soluciones 14
2.2.3.- rea de documentos 14
2.2.4.- Cuadro de herramientas 15
2.2.5.- Editor de propiedades 16
2.2.6.- Barras de herramientas y mens 16
2.3.- Trabajo con formularios Web y controles 16
2.3.1.- Creando la interfaz grfica del ejemplo 16
2.3.2.- Respondiendo al evento del botn 17
2.4.- Pero... cmo funciona esto por debajo? 18
2.5.- Los archivos de cdigo 19
2.5.1.- El archivo .aspx de interfaz de usuario 19
2.5.2.- El archivo .vb de lgica de la aplicacin 20
2.5.3.- En dnde se encuentra el nexo entre interfaz y lgica? 21
CAPTULO 3.- LOS CONTROLES DE ASP.NET 23

3.1.- Los controles HTML 23
3.2.- Los controles Web 24
3.2.1.- Adaptacin automtica al cliente 25
3.2.2.- Controles de terceras empresas 26
3.2.3.- Controles propios 27
3.3.- Controles Web de validacin 27
3.3.1.- Uso de los controles de validacin 28
3.3.2.- Colocar el foco en el error 29
3.4.- Controles de usuario 29
3.4.1.- Definicin de la funcionalidad pblica del control de 31
usuario
3.4.2.- Uso de los controles de usuario 31
CAPTULO 4.- TCNICAS DE TRABAJO Y CONSEJOS VARIOS 33

4.1.- Navegacin entre pginas 33
4.1.1.- Enlaces 33
4.1.2.- Redireccin 34
4.2.- Envo de datos entre pginas 34
2005 ii
4.3.- Transferir el control entre pginas 35

4.4.- Reutilizacin del cdigo en una aplicacin 35
CAPTULO 5.- ACCESO A DATOS CON ADO.NET 37

5.1.- Conceptos fundamentales de ADO.NET 37
5.1.1.- La capa conectada 38
5.1.2.- La capa desconectada 39
5.1.3.- Unin entre capa conectada y desconectada 40
5.1.4.- Otras clases dependientes de DataSet 40
5.1.5.- Vinculacin de datos a controles Web 40
5.2.- Acceso a datos manual 41
5.2.1.- Comandos de seleccin simples 41
5.2.2.- La clusula using 42
5.2.3.- Grupos de registros 43
5.2.4.- Ventajas e inconvenientes 44
5.3.- DataAdapter: puente entre dos mundos 44
5.3.1.- La clase DataSet 45
5.3.2.- Ventajas del uso de objetos DataSet 45
5.4.- Consultas parametrizadas 45
5.5.- Altas, bajas y modificaciones 47
5.5.1.-Trabajando desconectados 48
5.5.2.- Conciliando los cambios con el origen 49
5.5.3.- Definicin de los comandos 49
5.5.4.- Ventajas 50
CAPTULO 6.- ACCESO A DATOS CON VISUAL WEB DEVELOPER 2005 51

6.1.- Controles de datos 51
6.2.- Orgenes de datos 51
6.3.- Controles enlazados a datos 52
6.3.1.- Configurar un origen de datos 52
6.3.2.- Explotar el origen de datos 55
CAPTULO 7.- MASTER PAGES, TEMAS Y SKINS 59

7.1.- Qu son las Master Pages? 60
7.1.1.- Definicin de una Master Page 60
7.1.2.- Acceso a los elementos de una Master Page 61
7.2.- Temas y skins 62
7.2.1.- Hojas de estilo 62
7.2.2.- Temas y mscaras (Skins) 63
7.2.3.- La carpeta App_Themes 63
7.2.4.- Estructura de un archivo .skin 65
7.2.5.- Propiedades que se pueden personalizar 65
7.2.6.- Asignacin de temas 65
7.2.7.- Asignacin global de temas 66
7.2.8.- Clases de un mismo tipo de control 66
CAPTULO 8.- ESTADO DE LAS APLICACIONES 68

8.1.- Mantenimiento de sesiones 68
8.1.1.- Variables de sesin 68
8.1.2.- Funcionamiento bsico de las sesiones 69
8.1.3.- Sesiones sin cookies 69
8.1.4.- Duracin de las sesiones 69
8.2.- Informacin comn 70
8.2.1.- Almacenamiento en cach 70
8.3.- Cach de salida 71
8.3.1.- Directiva OutputCache 72
8.3.2.- Atributos de OutputCache 72
8.3.3.- Sustitucin post-cach 72
2005 iii
CAPTULO 9.- SEGURIDAD DE APLICACIONES 74

9.1.- Autenticacin de usuarios 74
9.1.1.- Autenticacin IIS / Windows 74
9.1.2.- Autenticacin Forms de ASP.NET 75
9.2.- Autorizacin de usuarios 76
9.2.1.- Autorizacin de URLs 76
9.2.2.- Autorizacin imperativa 77
9.3.- La nueva API: Membership y Roles 77
9.3.1.- Membership 78
9.3.2.- Roles 78
9.3.3.- Administracin de seguridad de sitios Web 78
9.4.- Los controles Web de seguridad 80
9.4.1.- El control Login 80
9.4.2.- El control LoginStatus 81
9.4.3.- El control LoginName 81
9.4.4.- El control LoginView 81
9.4.5.- Los controles restantes 82
CAPTULO 10.- INTRODUCCIN A LOS SERVICIOS WEB CON ASP.NET 83

10.1.- Qu son los Servicios Web? 83
10.1.1.- Un poco de historia: modelos de desarrollo 83
10.1.2.- Comunicacin entre componentes 85
10.1.3.- SOAP 86
10.1.4.- Breve historia de SOAP 86
10.1.5.- La base tecnolgica de SOAP 86
10.1.6.- Descubrimiento de servicios: WSDL y UDDI 87
10.2.- Creacin de un servicio Web 88
10.2.1.- Proyectos de servicios Web 88
10.2.2.- Archivos del servicio Web 88
10.2.3.- Tipos de datos 90
10.2.4.- Descripcin de mtodos 90
10.2.5.- parmetros opcionales y/o sobrecarga de mtodos Web 91
10.3.- Examinando manualmente un servicio Web creado con ASP.NET 91
10.4.- Consumo de servicios Web con ASP.NET 93
10.4.1.- Creando un proxy para utilizar el servicio 93
10.4.2.- Cambio de ubicacin del servicio 96
10.4.3.- Credenciales de acceso 96
2005 iv
CAPTULO 1
INTRODUCCIN A LA
PLATAFORMA .NET
ESTE CAPTULO PRESENTA CON CARCTER GENERAL LA PLATAFORMA .NET Y
CMO STA SE DIFERENCIA DE OTROS SISTEMAS DE DESARROLLO
TRADICIONALES, COMO ASP.
Simplificando mucho las cosas para poder dar una definicin corta y comprensible, se podra decir que la
plataforma .NET es un amplio conjunto de bibliotecas de desarrollo que pueden ser utilizadas por otras
aplicaciones para acelerar enormemente el desarrollo y obtener de manera automtica caractersticas
avanzadas de seguridad, rendimiento, etc...
En realidad .NET es mucho ms que eso ya que ofrece un entorno gestionado de ejecucin de aplicaciones,
nuevos lenguajes de programacin y compiladores, y permite el desarrollo de todo tipo de funcionalidades:
desde programas de consola o servicios Windows hasta aplicaciones para dispositivos mviles, pasando por
desarrollos de escritorio o para Internet. Son estos ltimos de los que nos ocuparemos en este libro. Pero
antes conviene conocer los fundamentos en los que se basa cualquier aplicacin creada con .NET, incluyendo
las que nos interesan.
1.1.- El entorno de ejecucin CLR
.NET ofrece un entorno de ejecucin para sus aplicaciones conocido como Common Language Runtime
o CLR. La CLR es la implementacin de Microsoft de un estndar llamado Common Language
Infrastructure o CLI. ste fue creado y promovido por la propia Microsoft pero desde hace aos es un
estndar reconocido mundialmente por el ECMA.
El CLR/CLI esencialmente define un entorno de ejecucin virtual independiente en el que trabajan las
aplicaciones escritas con cualquier lenguaje .NET. Este entorno virtual se ocupa de multitud de cosas
importantes para una aplicacin: desde la gestin de la memoria y la vida de los objetos hasta la seguridad y la
gestin de subprocesos.
Todos estos servicios unidos a su independencia respecto a arquitecturas computacionales convierten la CLR
en una herramienta extraordinariamente til puesto que, en teora, cualquier aplicacin escrita para funcionar
segn la CLI puede ejecutarse en cualquier tipo de arquitectura de hardware. Por ejemplo Microsoft dispone
de implementacin de .NET para Windows de 32 bits, Windows de 64 bits e incluso para Windows Mobile,
cuyo hardware no tiene nada que ver con la arquitectura de un ordenador comn.
1.2- El Lenguaje Intermedio y el CLS
Al contrario que otros entornos, la plataforma .NET no est atada a un determinado lenguaje de
programacin ni favorece a uno concreto frente a otros. En la actualidad existen implementaciones para
varias decenas de lenguajes que permiten escribir aplicaciones para la plataforma .NET. Los ms conocidos
son Visual Basic .NET, C# o J#, pero existen implementaciones de todo tipo, incluso de COBOL!.
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. Adems, como ya se ha comentado, es posible
ejecutar el cdigo .NET en diferentes plataformas y sistemas operativos.
1.3.- Cmo se consigue esta potente capacidad?
Dentro de la CLI, existe un lenguaje llamado IL (Intermediate Language o Lenguaje Intermedio) que
est pensado de forma independiente al procesador en el que se vaya a ejecutar. Es algo parecido al cdigo
2005 1
ensamblador pero de ms alto nivel y creado para un hipottico procesador virtual que no est atado a una
arquitectura determinada.
Cuando se compila una aplicacin 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 cdigo escrito en este lenguaje
intermedio. As, todos los lenguajes .NET se usan como capa de ms alto nivel para producir cdigo IL.
Un elemento fundamental de la CLR es el compilador JIT (just-in-time). Su cometido es el de compilar bajo

demanda y de manera transparente el cdigo escrito en lenguaje intermedio a lenguaje nativo del procesador
fsico que va a ejecutar el cdigo. Al final por lo tanto, lo que se ejecuta es cdigo nativo que ofrece un
elevado rendimiento.
Esto es cierto tambin para las aplicaciones Web escritas con ASP.NET y contrasta con las aplicaciones
basadas en ASP clsico que eran interpretadas, no compiladas, y que jams podran llegar al nivel de
desempeo que ofrece ASP.NET.
La siguiente figura muestra el aspecto que tiene el cdigo intermedio de una aplicacin sencilla y se puede
obtener usando el desemsamblador que viene con la plataforma .NET.
Figura 1.1. Cdigo en lenguaje intermedio obtenido con ILDASM.exe
Nota:
Puede ejecutar la utilidad de desensamblaje de .NET ejecutando el archivo ildasm.exe que encontrar en la
subcarpeta SDK de la carpeta de Visual Studio, ubicada normalmente en C:\program Files\Microsoft\Visual
Studio 8\SDK\v2.0\Bin o similar.
1.4.- La especificacin comn de los lenguajes y el sistema de tipos comunes
Para conseguir la interoperabilidad entre lenguajes no slo llega con el lenguaje intermedio, sino que es
necesario disponer de unas "reglas del juego" que definan un conjunto de caractersticas que todos los
lenguajes deben incorporar. A este conjunto regulador se le denomina Common Language Specification
(CLS) o, en castellano, especificacin comn de los lenguajes.
2005 2
Entre las cuestiones que regula la CLS se encuentran la nomenclatura, la forma de definir los miembros de los
objetos, los metadatos de las aplicaciones, etc... Una de las partes ms importantes de la CLS es la que se
refiere a los tipos de datos.
Si alguna vez ha programado la API de Windows o ha tratado de llamar a una DLL escrita en C++ desde
Visual Basic 6 habr comprobado lo diferentes que son los tipos de datos de VB6 y de C++. Para evitar este
tipo de problemas y poder gestionar de forma eficiente y segura el acceso a la memoria, la CLS define un
conjunto de tipos de datos comunes (Common Type System o CTS) que indica qu tipos de datos se
pueden manejar, cmo se declaran y se utilizan stos y de qu manera se deben gestionar durante la ejecucin.
Si nuestras bibliotecas de cdigo utilizan en sus interfaces hacia el exterior datos definidos dentro de la CTS
no existirn problemas a la hora de utilizarlos desde cualquier otro cdigo escrito en la plataforma .NET.
Cada lenguaje .NET utiliza una sintaxis diferente para cada tipo de datos. As, por ejemplo, el tipo comn
correspondiente a un nmero 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 programacin. 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
comn usar desde Visual Basic .NET el tipo Integer pensando que es de 16 bits cuando en realidad es capaz de
albergar nmeros mucho mayores. Tngalo 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).
1.5.- La biblioteca de clases de .NET
Todo lo que se ha estado comentando hasta ahora constituye la base de la plataforma .NET. Si bien es muy
interesante y fundamental, por s mismo no nos servira de mucho para crear programas si debisemos crear
toda la funcionalidad desde cero.
Obviamente esto no es as, y la plataforma .NET nos ofrece infinidad de funcionalidades "de fbrica" que se
utilizan como punto de partida para crear las aplicaciones. Existen funcionalidades bsicas (por ejemplo todo
lo relacionado con la E/S de datos o la seguridad) y funcionalidades avanzadas en las que se fundamentan
categoras enteras de aplicaciones (acceso a datos, creacin de aplicaciones Web...).
Toda esta funcionalidad est implementada en forma de bibliotecas de funciones que fsicamente se
encuentran en diversas DLL (bibliotecas de enlazado dinmico). A su conjunto se le denomina Base Classes
Library (Biblioteca de clases base o BCL) y forman parte integral de la plataforma .NET, es decir, no se
trata de aadidos que se deban obtener o adquirir aparte.
La siguiente figura ilustra a vista de pjaro la arquitectura conceptual de la plataforma .NET. En ella se
pueden observar los elementos que se han mencionado en apartados anteriores (lenguajes, CLR, CLS...) y en
qu lugar de se ubican las bibliotecas de clases base:
2005 3
Figura 1.2. Distintos elementos de la plataforma .NET y cmo se relacionan entre s.
Resulta muy til para comprender lo explicado hasta ahora. No se preocupe si hay elementos que no conoce,
ms adelante los estudiaremos todos.
Todo lo que se encuentra en la BCL forma parte de la plataforma .NET. De hecho existe tal cantidad de
funcionalidad integrada dentro de estas bibliotecas (hay decenas de miles de clases) que el mayor esfuerzo que
todo programador que se inicia en .NET debe hacer es el aprendizaje de las ms importantes. De todos
modos Visual Studio ofrece mucha ayuda contextual (documentacin, Intellisense...) y una vez que se aprenden
los rudimentos resulta fcil ir avanzando en el conocimiento de la BCL a medida que lo vamos necesitando.
1.6.- Los espacios de nombres
Dada la ingente cantidad de clases que existen debe haber algn modo de organizarlas de un modo coherente.
Adems hay que tener en cuenta que podemos adquirir ms funcionalidades (que se traducen en clases) a
otros fabricantes, por no mencionar que crearemos continuamente nuevas clases propias.
Para solucionar este problema de organizacin existen en todos los lenguajes .NET los espacios de
nombres o namespaces.
Un espacio de nombres no es ms que un identificador que permite organizar de modo estanco las clases que
estn contenidas en l as como otros espacios de nombres.
As, por ejemplo, todo lo que tiene que ver con el manejo de estructuras de datos XML en la plataforma
.NET se encuentra bajo el espacio de nombres System.Xml. La funcionalidad fundamental para crear
aplicaciones Web est en el espacio de nombres System.Web. ste a su vez contiene otros espacios de
nombres ms especializados como System.Web.Caching para la persistencia temporal de datos,
System.Web.UI.WebControls, que contiene toda la funcionalidad de controles Web para interfaz de
usuario, etc...
1.7.- Acceso a datos con ADO.NET
El acceso a fuentes de datos es algo indispensable en cualquier lenguaje o plataforma de desarrollo. La parte
de la BCL que se especializa en el acceso a datos se denomina de forma genrica como ADO.NET.
2005 4
Si usted ha programado con Visual Basic 6.0 o con ASP, ha empleado en su cdigo con total seguridad la
interfaz de acceso a datos conocida como ADO (ActiveX Data Objects), puede que combinado con ODBC
(Open Database Connectivity). Si adems es usted de los programadores con solera y lleva unos cuantos aos en
esto es probable que haya usado RDO o incluso DAO, todos ellos mtodos mucho ms 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
propsito anlogo en el vetusto ADO.
ADO.NET es un modelo de acceso mucho ms orientado al trabajo desconectado de las fuentes de datos
de lo que nunca fue ADO. Si bien este ltimo ofreca la posibilidad de desconectar los Recordsets y ofreca una
forma de serializacin de estos a travs de las diferentes capas de una aplicacin, el mecanismo no es ni de
lejos tan potente como el que nos ofrece ADO.NET.
El objeto ms importante a la hora de trabajar con el nuevo modelo de acceso a datos es el DataSet. Sin
exagerar demasiado podramos calificarlo casi como un motor de datos relacionales en memoria. Aunque hay
quien lo asimila a los clsicos Recordsets su funcionalidad va mucho ms all como se ver en el
correspondiente mdulo.
1.8.- Arquitectura de ADO.NET
El concepto ms importante que hay que tener claro sobre ADO.NET es su modo de funcionar, que se
revela claramente al analizar su arquitectura:
Figura 1.3.- Arquitectura de ADO.NET
Existen dos capas fundamentales dentro de su arquitectura: la capa conectada y la desconectada.
2005 5
1.8.1.- Capa conectada
La primera de ellas contiene objetos especializados en la conexin con los orgenes de datos. As, la clase
genrica Connection se utiliza para establecer conexiones a los orgenes de datos. La clase Command se
encarga de enviar comandos de toda ndole al origen de datos. Por fin la clase DataReader est especializada
en leer los resultados de los comandos mientras se permanece conectado al origen de datos.
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 implementacin 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, adems de otras particularidades
que se deben contemplar. Un proveedor de datos de ADO.NET es una implementacin 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 cuestin.
As, por ejemplo, las clases especficas 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 clsico no hay una nica clase Connection o Command que se use en cada
caso, si no que existen clases especializadas para conectarse y recuperar informacin 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
cdigo independiente del origen de datos. Todo lo contrario. La plataforma .NET ofrece grandes facilidades de
escritura de cdigo genrico basadas en el uso de herencia e implementacin de interfaces. De hecho la
versin 2.0 de .NET ofrece muchas novedades especficamente 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 travs 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 estn utilizando (ODBC u OLEDB). Un programador novel puede sentir la
tentacin de utilizar siempre el proveedor puente para OLEDB y as escribir cdigo 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.
1.8.2.- Capa desconectada
Una vez que ya se han recuperado los datos desde cualquier origen de datos que requiera una conexin 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. Adems, 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 conexin. A veces nicamente necesitamos un almacn de datos temporal pero que ofrezca
caractersticas avanzadas de gestin y acceso a la informacin.
Por otra parte las conexiones con las bases de datos son uno de los recursos ms escasos con los que
contamos al desarrollar. Su mala utilizacin es la causa ms frecuente de cuellos de botella en las aplicaciones
y de que stas no escalen como es debido. Esta afirmacin es especialmente importante en las aplicaciones
Web en las que se pueden recibir muchas solicitudes simultneas 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 informacin entre capas de una aplicacin. stas pueden encontrarse distribuidas por
diferentes equipos, e incluso en diferentes lugares del mundo gracias a Internet. Por ello es necesario disponer
de algn modo genrico 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.
2005 6
Todo esto y mucho ms es lo que nos otorga el uso de los objetos DataSet. Es obvio que no se trata de
tareas triviales, pero los objetos DataSet estn pensados y diseados con estos objetivos en mente. Como
podremos comprobar ms 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 caractersticas de los DataSet es que permiten gestionar simultneamente 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 tcnica avanzada que consiste en crear tipos nuevos de DataSet especializados en la gestin de
una informacin concreta (por ejemplo un conjunto de tablas relacionadas). Estas nuevas tipos clases se
denominan genricamente DataSet Tipados, y permiten el acceso mucho ms cmodo a los datos que
representan, verificando reglas de negocio, y validaciones de tipos de datos ms estrictas.
1.9.- 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 construiramos 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 tambin el nombre genrico 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 ms rico al que ofreca el entorno de desarrollo integrado de Visual Basic.
Figura 1.4.- Diseador de interfaces de aplicaciones de escritorio con Windows Forms en Visual
Studio 2005.
2005 7
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 mxima 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 cdigo y no es necesario (aunque s muy recomendable) emplear el
diseador grfico de Visual Studio para crearlas.
Este es el aspecto que presenta parte del cdigo que genera la interfaz mostrada en la anterior figura:
F
Figura 1.5.- Cdigo autogenerado por Visual Studio para crear la interfaz de la figura anterior.
Al contrario que en Visual Basic tradicional, en donde siempre existan instancias por defecto de los
formularios que podamos usar directamente, en .NET es necesario crear un objeto antes de poder hacer uso
de los formularios:
Dim frm As New MiFormulario

frm.Show()
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 diseador (movindolos, alinendolos...),
definir mrgenes entre ellos o hacer que se adapten al tamao de su contenedor.
Este tipo de aplicaciones se salen del mbito de este libro por lo que no se profundizar ms en ellas.
1.10.- Aplicaciones Web Forms
Tradicionalmente las aplicaciones Web se han desarrollado siguiendo un modelo mixto que intercalaba cdigo
HTML y JavaScript propio de pginas Web (parte cliente), junto con cdigo que se ejecutara 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.
2005 8
En el modelo orientado a eventos se define la interfaz de usuario colocando controles en un contenedor y se

escribe el cdigo que actuar como respuesta a las interacciones de los usuarios sobre estos controles. Si
conoce el diseador de VB6 o de Windows Forms mencionado en el apartado anterior sabe exactamente a
qu nos referimos.
Hacer esto en una aplicacin de escritorio no tiene mayor dificultad ya que todo el cdigo se ejecuta en el
mismo lugar. La principal caracterstica de las aplicaciones Web sin embargo es que la interfaz de usuario (lo
que los usuarios de la aplicacin ven) se ejecuta en un lugar diferente al cdigo de la aplicacin 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 conexin entre dos llamadas consecutivas.
Por ejemplo, la siguiente figura ilustra el cdigo que es necesario escribir en ASP para disponer de una pgina
que rellena una lista de seleccin con unos cuantos nombres (podran salir de una base de datos y an sera
ms complicado), y que dispone de un botn que escribe un saludo para el nombre que se haya elegido de la
lista.
Figura 1.6.- Cdigo ASP sencillo que genera una lista de seleccin y saluda al pulsar un botn.
Obviamente se podra haber simplificado sin enviar el formulario al servidor usando JavaScript en el cliente
para mostrar el saludo, pero la intencin es ilustrar la mezcla de cdigo de cliente y de servidor que existe en
este tipo de aplicaciones.
Las principales desventajas de este tipo de codificacin son las siguientes:
1. No existe separacin entre el diseo y la lgica de las aplicaciones. Si queremos cambiar

sustancialmente la apariencia de la aplicacin Web lo tendremos bastante complicado puesto que el
cdigo del servidor est mezclado entre el HTML.
2. En ASP clsico no existe el concepto de control para la interfaz de usuario. Lo nico que hay
es HTML y JavaScript que se deben generar desde el servidor. En el ejemplo de la figura para
generar un control de lista con unos elementos no podemos asignar una propiedad de la lista
(porque no existe tal lista), sino que tenemos que crear un bucle que genere los elementos HTML
necesarios para generarla. Tampoco disponemos de un diseador visual que nos permita gestionar
los controles y elementos HTML existentes, y menos cuando stos se encuentran mezclados con el
cdigo del servidor.
2005 9
3. No disponemos de forma de detectar en el servidor que se ha realizado algo en el cliente. El

cliente se encuentra desconectado desde el momento en que se termina de devolver la pgina. Slo
se recibe informacin en el servidor cuando se solicita una nueva pgina o cuando se enva un
formulario tal y como se hace en el ejemplo, debindonos encargar nosotros de averiguar si la
peticin es la primera vez que se hace o no, y de dar la respuesta adecuada. En cualquier caso es
mucho menos intuitivo que el modelo de respuesta a eventos de una aplicacin de escritorio.
4. No existe constancia del estado de los controles de cada pgina entre las llamadas. En cada
ejecucin de la pgina tendremos que recrear completamente la salida. Por ejemplo si pulsamos en el
botn Di Hola tenemos que escribir adems de la etiqueta Hola, nombre el resto de la pantalla,
incluyendo la lista con todos los nombres dejando seleccionado el mismo que hubiese antes. Si estos
nombres viniesen de una base de datos esto puede ser todava ms ineficiente y tendremos que
buscar mtodos alternativos para generarlos ya que en ASP tampoco se deben almacenar en los
objetos de sesin y/o aplicacin Recordsets resultado de consultas.
5. No existe el concepto de Propiedad de los controles. En una aplicacin Windows asignamos el

texto de un campo usando una propiedad (por ejemplo Text1.Text = "Hola") y sta se asigna y
permanece en la interfaz sin que tengamos que hacer nada. En una aplicacin Web clsica tenemos
que almacenarlas en algn sitio (una variable de sesin o un campo oculto) para conservarlas entre
diferentes peticiones de una misma pgina.
6. Los controles complejos no tienen forma de enviar sus valores al servidor. Si intentamos crear
una interfaz avanzada que utilice tablas y otros elementos que no son controles de entrada de datos
de formularios de HTML tendremos que inventarnos mecanismos propios para recoger esos datos y
enviarlos al servidor.
La principal aportacin de ASP.NET al mundo de la programacin es que ha llevado a la Web el paradigma

de la programacin orientada a eventos propia de aplicaciones de escritorio, ofreciendo:
Separacin entre diseo y lgica.

Componentes de interfaz de usuario, tanto estndar como de terceras empresas o propios.
Diseadores grficos.
Eventos.
Estado.
Enlazado a datos desde la interfaz.
Esto como se ver marca un antes y un despus en la programacin para Internet.
2005 10
CAPTULO 2
FUNDAMENTOS DEL
DESARROLLO DE APLICACIONES
WEB
EN ESTE CAPTULO APRENDEREMOS TODO LO FUNDAMENTAL ACERCA DEL
DESARROLLO DE APLICACIONES WEB CON ASP.NET 2.0, Y EN CONCRETO MEDIANTE
EL USO DE VISUAL WEB DEVELOPER 2005 EXPRESS EDITION. AL TERMINAR EL
MDULO ESTAR USTED PREPARADO PARA TRABAJAR EN EL ENTORNO Y CREAR
APLICACIONES WEB SIN ENLACE A DATOS (ESTO SE APRENDER MS ADELANTE,
EN EL MDULO CORRESPONDIENTE).
Ms que una evolucin sobre ASP, ASP.NET es una autntica revolucin en el mundo del desarrollo Web, y
no slo en el mbito relacionado con Microsoft. Lo que mejor define al desarrollo combinado con ASP.NET
2.0 y Visual Studio es que ha equiparado la creacin de aplicaciones para Internet a lo que era comn en entornos de
escritorio, salvando las inherentes dificultades que ello conlleva de forma transparente al programador.
Los programadores de Visual Web Developer 2005 disponen de todo lo que "siempre" han disfrutado los
programadores de Windows: diseadores visuales, asistencia avanzada contextual, cdigo compilado de alto
rendimiento, transparencia acerca de dnde se ejecuta cada parte del cdigo, enlace a datos, rejillas, etc...
2.1.- Las pginas ASPX
Si nos vamos a lo fundamental es posible crear una pgina ASP.NET usando el bloc de notas y sin saber nada
de la plataforma .NET y de sus diferentes espacios de nombre.
Las pginas de servidor de ASP.NET son en esencia archivos de texto que contienen HTML y etiquetas y
que tienen una extensin '.aspx'. Por ello se les denomina de modo genrico pginas ASPX.
Al igual que las pginas ASP clsicas soportan el uso de etiquetas <% %> para delimitar bloques de cdigo. 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 ms recomendable. Sin embargo para familiarizarnos haremos un ejemplo sencillo.
Figura 2.1.- Pgina ASPX sencilla
2005 11
El cdigo de la figura anterior no se distingue de una pgina ASP clsica salvo por la extensin del archivo
(.aspx en lugar de .asp). Sin embargo si navegamos hasta esta pgina (ubicada en el raz de nuestro servidor
IIS) veremos que el resultado es el que esperbamos:
Figura 2.2.- Resultado del cdigo anterior
De todos modos, aunque no podamos percibirla, ya existe una sustancial diferencia con una pgina ASP: el
pequeo fragmento de cdigo que hemos incluido se ha compilado antes de ejecutarlo, en lugar de haberse
interpretado como en ASP. Obviamente en este caso no ofrece ventaja alguna, pero es importante conocer
esta caracterstica pues nuestras aplicaciones obtendrn un mayor rendimiento por el mero hecho de ser
ASP.NET.
2.1.1.- Ms cdigo
Siguiendo con el ejemplo vamos a aadir un poco ms de cdigo para comprobar hasta que punto son
compatibles las pginas ASPX con el cdigo ASP.
Si lo modificamos para que tenga el siguiente aspecto:
Figura 2.3.- Ms cdigo aadido a la pgina ASPX
Ahora durante la carga (o la recarga) de la pgina verificamos si se le est pasando un parmetro por POST,
en cuyo caso sustituimos la caja de texto por un saludo al nombre que se le est pasando:
Figura 2.4.- Resultado de la ejecucin.
2.1.2.- Estupendo, pero... en qu hemos mejorado?
Este ejemplo nos ha servido para ver qu ASPX sigue siendo compatible en cierta medida con ASP, y que
slo por este hecho ya mejoraremos la escalabilidad de las pginas. De todos modos el cambio de la extensin
2005 12
del archivo slo funcionar en las pginas ms sencillas. En cdigo no trivial tenemos una probabilidad
tendente a 1 de que no haya esa suerte.
Adems, aunque as fuera, no habramos ganado demasiado: seguiramos con cdigo de cliente y de servidor
entremezclado y difcil de mantener y no tendramos ninguna de las ventajas que hemos mencionado antes. Si
bien podemos escribir cdigo ASP.NET de la manera correcta slo con el bloc de notas, la mejor forma de
desarrollar pginas Web con ASP.NET es usando Visual Web Developer 2005, que como veremos enseguida
nos ofrece una forma visual de trabajo junto con una separacin estricta entre el cdigo y la interfaz de
usuario, que es lo que pretendamos.
2.2.- El entorno de desarrollo: VWD Express 2005
Visual Web Developer (VWD) es el entorno de desarrollo de aplicaciones Web para la versin 2.0 de la
plataforma .NET. Ofrece todo tipo de herramientas para facilitar el trabajo del programador: diseadores
grficos de pginas y clases, asistentes de uso de bases de datos, un servidor web de desarrollo, ayuda a la
escritura de cdigo, y en general todo lo que se espera de un entorno de desarrollo rpido moderno y mucho
ms todava.
Para crear un nuevo proyecto de VWD utilice el men ArchivoNuevoSitio Web. Al hacerlo aparecer un
dilogo como el de la figura:
Figura 2.5.- El dilogo de nuevo proyecto web de VWD.
En l tenemos la oportunidad de elegir qu tipo de proyecto vamos a crear (por defecto un sitio web de
ASP.NET), en qu ubicacin fsica queremos crearlo (lo normal ser en nuestro disco duro pero podramos
elegir un sitio gestionado por FTP o HTTP) y con qu lenguaje de programacin.
Existen diferentes lenguajes que nos sirven para crear el cdigo de nuestras pginas. Dado que en la prctica
todos tienen las mismas capacidades escoger uno u otro es una cuestin de eleccin personal. A mi, por
ejemplo, me gusta mucho Visual C#, pero a un programador proveniente del mundo Java le llamar ms la
atencin Visual J#. Tradicionalmente en entornos Microsoft las aplicaciones Web se han programado con
VBScript, un subconjunto de Visual basic, por lo que en este libro hemos optado por Visual basic .NET.
2.2.1.- Explorando el entorno
Tras crear un proyecto nuevo, el entorno tiene un aspecto similar a este:
2005 13
Figura 2.6.- El entorno de desarrollo de VWD tras crear un proyecto.
Antes de aprender a manejar VWD vamos a ponernos en situacin conociendo los distintos elementos que
forman parte del entorno.
2.2.2.- Explorador de soluciones
Este elemento contiene un rbol con los proyectos en los que estamos trabajando y los diferentes archivos y
carpetas que forman parte de ellos.
Nada ms crear un nuevo proyecto Web slo existe una carpeta llamada App_Data, y una pgina ASPX
creada de forma predeterminada que est vaca y es con la que comenzaremos a trabajar.
Los botones de la parte superior se usan para realizar diversas acciones sobre el elemento que tengamos
seleccionado. Por ejemplo en el caso de la pgina podemos abrir su diseo o su cdigo pulsando
respectivamente el tercer y cuarto botones por la derecha.
2.2.3.- rea de documentos
2005 14
Figura 2.7.- rea de documentos mostrando un editor de HTML.
Es la zona situada en el centro del entorno de desarrollo. Contiene los diferentes editores de cdigo as como
diseadores de diversos tipos (de interfaz de usuario, de clases, de DataSets...). Es en donde pasaremos la
mayor parte del tiempo trabajando.
2.2.4.- Cuadro de herramientas
Figura 2.8.- Cuadro de herramientas y detalle de un algunos grupos de ste.
El cuadro de herramientas contiene los diferentes elementos que podemos utilizar para la definicin de la
interfaz de usuario de nuestra aplicacin, as como algunos otros componentes no visuales que tambin se
pueden arrastrar hacia el diseador visual de pginas Web. Est situado por defecto en el lateral izquierdo del
entorno.
2005 15
2.2.5.- Editor de propiedades
Al igual que en Visual Basic 6.0, Frontpage y otros entornos, el editor

de propiedades nos permite ajustar los valores de las propiedades en
tiempo de diseo de los objetos que hayamos seleccionados.
Este editor sirve para ajustar las propiedades de todos los objetos que
podamos utilizar en el entorno: tanto de los controles que se arrastran
sobre un diseador como de los propios archivos del explorador de
soluciones y las etiquetas HTML o XML, etc...
Algunas propiedades se editan directamente en el espacio disponible y

otras lanzan un asistente o un diseador que nos ayuda con la tarea.
Se pueden ver las propiedades ordenadas alfabticamente o bien
agrupadas en diferentes categoras (opcin por defecto). Adems de las
propiedades tambin se pueden ajustar los gestores de eventos de los
objetos usando el penltimo botn por la derecha. En la parte inferior
se obtiene una concisa ayuda sobre cada propiedad seleccionada.
2.2.6.- Barras de herramientas y mens
Se sitan en la parte superior y dan acceso al resto de las caractersticas de la herramienta de trabajo. Segn el
contexto en el que nos encontremos las barras de herramientas que veremos sern distintas. Visual Studio se
encarga de mostrar y ocultar la ingente cantidad de barras disponibles mostrando en cada caso slo las que
necesitemos. Esto racionaliza el acceso a los elementos de la interfaz que de otro modo seran inmanejables.
2.3.- Trabajo con formularios Web y controles
El entorno de trabajo que hemos explorado es muy intuitivo y fcil de utilizar. En la mayor parte de los casos
vamos a hacer uso nicamente de los tres diseadores principales: diseador visual de formularios Web,
diseador de HTML y editor de cdigo de VB.NET.
Creemos un ejemplo sencillo desde cero para ver cmo se trabaja. Luego estudiaremos la estructura de los
archivos generados para comprender su funcionamiento. El ejemplo es el mismo que hemos creado en el
primer apartado pero utilizando el modo de programar de ASP.NET y no el cdigo "espaguetti" tpico de
ASP clsico que hemos utilizado antes.
2.3.1.- Creando la interfaz grfica del ejemplo
Desde VWD cree un nuevo proyecto de sitio Web. Abra el diseador de la pgina por defecto que se crea
(Default.aspx) haciendo doble-clic sobre ella. Aada 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 tamao
grande y color rojo.
Justo debajo agregue un control TextBox, y establezca su propiedad ID como "Nombre", Width como 200px
y MaxLength ajstela a 40.
A continuacin introduzca un botn (Button) y asgnele el texto "Saludar" (propiedad Text) y otrguele el
nombre de "cmdSaludar".
2005 16
Por fin aada una etiqueta ms 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 debera ser muy similar a este:
Figura 2.9.- Aspecto del ejemplo tras haber aadido los controles.
2.3.2.- Respondiendo al evento del botn
Para saludar al usuario con el nombre que introduzca en el campo de texto debemos responder a la pulsacin
del botn. En ASP clsico tendramos que enviar un formulario a otra pgina (o a la misma) y ver qu valores
no es estn pasando para actuar en consecuencia. En ASP.NET esto no es necesario ya que trabajaremos
segn el clsico paradigma orientado eventos, respondiendo a las acciones del usuario.
En este caso debemos interceptar la pulsacin del botn por parte del usuario verdad?. Pues lo nico que
tendremos que hacer es escribir un manejador para el evento Click del botn, algo que resultar familiar e
intuitivo a los programadores de VB6. Para ello haga doble-clic sobre el botn en el diseador. Esto har que
se abra el editor de cdigo y que automticamente aparezca un manejador de eventos para el evento Click,
que es el predeterminado de los botones:
Figura 2.10.- Manejador del evento Click generado automticamente por el editor.
Al igual que en VB6 desde el cdigo del evento (que se ejecutar en el servidor, atencin!) podemos hacer
referencia a cualquier control de la pgina y acceder a sus mtodos y propiedades. De este modo se puede
escribir el siguiente cdigo simple:
Es decir, se concatena un saludo al nombre introducido en el campo de texto asignndoselo como texto a
mostrar a la etiqueta oculta, y se hace visible sta usando su propiedad Visible.
Si ejecutamos ahora el ejemplo (pulsando F5 o el botn correspondiente en la barra de herramientas)

veremos que funciona sin problemas:
2005 17
Figura 2.11.- Nuestro ejemplo antes y despus de pulsar el botn.
Ntese que no hemos aadido formulario alguno, ni tampoco JavaScript, y que en realidad para nosotros es
transparente el modo en como se gestionan los eventos e incluso que lo que estamos creando sea una
aplicacin Web. No hemos usado HTML y (hasta cierto punto) nos da igual que el cdigo se ejecute en el
servidor o en el cliente.
2.4.- Pero... Cmo funciona esto por debajo?
Si echamos un vistazo al cdigo de la pgina generada veremos que, aparte del HTML que es ms o menos
obvio que debera haber dados los controles que hemos utilizado, existe tambin bastantes lneas de cdigo
JavaScript y algunos campos ocultos.
Los campos ocultos se utilizan para almacenar informacin sobre la pgina y el cdigo JavaScript se ocupa de
su mantenimiento y de enviar el formulario al servidor ante determinadas acciones del usuario (simulando los
eventos).
Uno de los campos ocultos ms importantes es el que se refiere al ViewState.
Figura 2.12.- Viewstate de una pgina sencilla.
El ViewState - que se podra traducir como "Estado de Visualizacin" - recoge de manera automtica el
estado y el contenido de los controles de una pgina. Esta informacin se utiliza para dejarlos como estaban
en cada recarga de la pgina.
Cuando pulsamos el botn de nuestro ejemplo la pgina se recarga y todo lo que contiene debe estar igual
que antes de hacerlo o no podramos asimilarlo a un formulario. A excepcin de una pequea demora por el
viaje de ida y vuelta al servidor, para el usuario no debe haber sensacin de recarga de la pgina. El
ViewState se encarga de ello.
Nota:
A cada viaje de ida y vuelta de nuestra pgina al servidor como consecuencia de un evento en el cliente se le
2005 18
denomina PostBack. Se puede averiguar si la carga actual de la pgina es la primera o se trata de un PostBack
consultando el valor booleano de la propiedad IsPostBack de la pgina (Me.IsPostBack).
Como se aprecia en la figura se trata de informacin sobre la jerarqua de controles de la pgina codificada
para su envo al servidor. Al recibirla, la clase Page de la que hereda nuestra pgina se encarga de
decodificarlo, procesarlo e inicializar de nuevo el estado de cada control segn la informacin facilitada, sin
necesidad de trabajo por nuestra parte.
Por otra parte, para determinar qu evento se ha producido, se emplean tambin dos campos ocultos y un
poco de JavaScript:
Figura 2.13.- Campos ocultos de informacin sobre eventos
Figura 2.14.- JavaScript asociado a la notificacin de eventos al servidor.
Cuando se efecta alguna accin el JavaScript de la pgina se encarga de rellenar estos campos y provocar un
PostBack de la pgina. El evento es detectado en el servidor a travs de estos campos ocultos y se gestiona
adecuadamente por ASP.NET, que se encarga de notificar los eventos.
Los mecanismos de ViewState y de PostBack son los responsables de que, a efectos prcticos, podamos trabajar
en la Web utilizando el paradigma de programacin orientada a eventos.
Imagnate tener que gestionar eso t mismo con cdigo propio!
2.5.- Los archivos de cdigo
Centremos nuevamente nuestra atencin en los archivos de cdigo de servidor que tenemos en Visual Web
Developer. Existen dos: uno que define la interfaz de usuario y otro para la lgica de la aplicacin. Veamos
cmo estn formados y cul es el nexo de unin entre ellos.
2.5.1.- El archivo .aspx de interfaz de usuario.
En realidad todo el cdigo se ejecuta en el servidor y, por poco intuitivo que sea para un programador Web
tradicional, el evento desencadenado por la pulsacin se gestiona en el servidor, no en el cliente. Veamos
cmo funciona.
2005 19
Para crear la interfaz de usuario slo hemos tenido que arrastrar controles Web desde el cuadro de
herramientas al diseador. Por detrs lo que ha estado ocurriendo es que el cdigo HTML de la pgina ha
estado creciendo hasta ser como el siguiente:
Figura 2.15.- Cdigo HTML de la interfaz de usuario ASPX.
Vemos que, sin que conscientemente lo hayamos hecho, se ha creado un formulario (Form1) que al carecer de
un atributo ACTION se enviar a si mismo. Este formulario (y otros elementos tienen asignado el atributo
runat="server". ste se usa para indicar que son controles de servidor y que, como tales, debern estar
disponibles para el cdigo que se ejecuta en el servidor, como por ejemplo nuestro manejador del evento.
Nota:
En las pginas ASPX slo se recomienda el uso de un formulario, que es adems el formulario que incluye
automticamente el entorno de desarrollo. Lo cierto es que no se trata de limitacin alguna puesto que la
filosofa 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 lnea) 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 pgina ASP.NET instancia dichas clases y las pone a disposicin de nuestro cdigo pasando todo
ello inadvertido para nosotros.
2.5.2.- El archivo .vb de lgica de la aplicacin
Por otro lado existe un archivo con extensin .vb, dependiente, segn el explorador de proyectos, del archivo
.aspx anterior.
2005 20
Figura 2.16.- Archivo .vb de lgica de la aplicacin
ste contiene la "lgica" de la aplicacin, 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
pulsar el botn. En una aplicacin real podra contener multitud de cosas ms.
Nota:
Aunque es muy tentador abusar de la capacidad de crecimiento de estos archivos de cdigo, suele ser mucho
ms 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 pginas aspx. Veremos cmo hacerlo
en breve en este libro.
Desde este archivo de cdigo podemos responder a cualquier evento de los controles de interfaz de usuario o
de la propia pgina, y acceder a sus mtodos y propiedades.
Gracias a la existencia de estos dos archivos podemos independizar el aspecto de la aplicacin (la interfaz) de
lo que queremos hacer con ella. De hecho incluso se podra programar con dos equipos distintos, cada uno
encargado de una cosa. Esta constituye tambin una de las grandes ventajas de ASP.NET.
2.5.3.- En dnde se encuentra el nexo entre interfaz y lgica?
Tras esta pregunta tan aparentemente filosfica se encuentra una respuesta muy sencilla: la directiva de pgina
@Page y la existencia de clases parciales en .NET 2.0.
Si nos fijamos en el cdigo de la pgina ASPX de la figura anterior, la primera lnea es una directiva @Page
con diversos atributos.
AutoEventWireUp: indica si los eventos se deben generar de forma automtica o no. A los efectos
de este curso no hablaremos ms de l.
CodeFile: este atributo es especfico de Visual Studio y le indica cul es el archivo de cdigo (.vb)
que contiene la definicin de la lgica de la pgina.
Inherits: indica de qu clase heredar la clase auto-generada por ASP.NET para gestionar los
contenidos de la pgina ASPX actual (repase el primer vdeo de este mdulo acerca de cdigo
compilado).
Nota:
CodeFile es un atributo nuevo en ASP.NET 2.0 y modifica el modelo utilizado en Visual Studio 2002 y 2003
para crear cdigo de lgica de negocio para las pginas, 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 cdigo necesario
para crear las pginas ASPX, ya que no hay que declarar los controles ni inicializarlos en el cdigo de lgica.
Si ahora os fijamos en el cdigo de lgica de la pgina (figura 2.10 anterior), veremos que se define
parcialmente una clase _Default. Y este es el nexo de unin entre ambos archivos.
2005 21
Cuando ASP.NET genera la pgina primero completa automticamente el cdigo de la clase _Default con otra
implementacin parcial de sta en la que se definen los controles de la pgina (el cdigo que ha
desaparecido respecto a las versiones anteriores del entorno). Luego define una nueva clase especfica para la
pgina que hereda de _Default y es en ella donde inicializa los controles y hace el nexo entre la interfaz y la
lgica. Es por este motivo que ahora los manejadores de eventos de la clase se declaran con accesibilidad
protected, para que puedan utilizarse desde la clase derivada.
Nota:
A esta novedosa forma de separar (y al mismo tiempo unir en tiempo de ejecucin) la interfaz de la lgica hay
quien la denomina "code-beside", como homenaje al hasta ahora utilizado "code-behind" de ASP.NET 1.x.
2005 22
CAPTULO 3
LOS CONTROLES DE ASP.NET

ASP.NET OFRECE UNA GRAN CANTIDAD DE CONTROLES QUE SE PUEDEN USAR EN
LOS DESARROLLOS DE APLICACIONES WEB. EN EL CAPTULO ANTERIOR HEMOS
PODIDO VER SOMERAMENTE ALGUNOS DE ELLOS EN FUNCIONAMIENTO, MIENTRAS
QUE SUPIMOS DE LA EXISTENCIA DE OTROS AL VERLOS EN EL CUADRO DE
HERRAMIENTAS.
EN ESTE CAPTULO VAMOS A CONOCER DESDE UN PUNTO DE VISTA GENERAL LOS
TIPOS DE CONTROLES EXISTENTES Y APRENDEREMOS, CON MS DETALLE, LA
UTILIZACIN UNOS CONTROLES MUY TILES: LOS CONTROLES DE VALIDACIN.
3.1.- Los controles HTML
Hasta ahora hemos visto lo sencillo que resulta trabajar con controles de
servidor arrastrndolos y soltndolos en los formularios Web. Los
controles que hemos utilizado se definen usando una sintaxis especial
(<asp:...>) y como hemos podido comprobar responden a un
comportamiento complejo.
Antes de ASP.NET cuando necesitbamos usar un control en una pgina

emplebamos alguno de los definidos en HTML: controles de tipo
<input>, <textarea> o <img> entre otros. Con ASP.NET disponemos
tambin de la posibilidad de usarlos.
Desde el cuadro de herramientas disponemos del grupo HTML (ver

figura adjunta) que son controles equivalentes a los de HTML.
Podemos arrastrarlos y soltarlos sobre nuestro formulario al igual que los

otros, pero al contrario que stos no se ejecutarn por defecto en el
servidor. Slo aparecer su sintaxis HTML pura y dura.
Se trata de controles muy tiles en determinadas ocasiones en las que no necesitamos todas las ventajas que
nos ofrecen los controles de servidor, por ejemplo:
No vamos a acceder a sus mtodos y propiedades desde el servidor.

Quiz no necesitamos que mantengan su estado o respondan a evento alguno.
El uso del campo oculto ViewState puede cargar la pgina en exceso si hay muchos controles, por
no mencionar que hay que crear clases en el servidor que los representen cuando se procesa la
pgina. Todo ello reduce la respuesta de la pgina.
Por supuesto podemos convertirlos en controles de servidor simplemente asignando su atributo runat, as:
<input id="Button1" type="button" value="button" runat="server" />
Como vemos es un botn corriente de HTML al que se la ha aadido el atributo runat. Slo con esto hemos
conseguido que el control est disponible desde nuestro cdigo de servidor y disfrutaremos de todas las
cualidades conocidas: acceso a sus propiedades y mtodos, conservacin del estado, etc...
En el rea de diseo del formulario es muy fcil distinguir los controles de servidor de los HTML porque los
primeros tienen un pequeo tringulo verde que los marca. En la siguiente figura todos los controles se
ejecutan en el servidor excepto el botn "button" de la derecha.
2005 23
Figura 3.1.- Distincin entre Controles de servidor y HTML
Los controles HTML, en cualquier caso, son mucho ms sencillos que los otros controles Web. Tienen
menos propiedades y eventos, los cuales se suelen corresponder adems con los mismos que tienen en
HTML+Javascript. Son ms adecuados cuando no requerimos una gran flexibilidad y queremos cargar la
pgina lo mnimo posible.
Esta figura ilustra la jerarqua de los controles HTML en ASP.NET:
Figura 3.2.- Jerarqua de los controles HTML
Todos ellos, obviamente, heredan de la clase Object, pero tambin heredan de la clase base HtmlControl
que est contenida en el espacio de nombres System.Web.UI.Control.
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.
3.2.- Los controles Web
Son controles nativos de ASP.NET. Aunque algunos parecen asimilables a controles HTML, todos van
mucho ms all en cuanto a caractersticas y capacidades. De hecho, aunque algunos son relativamente
sencillos (como una etiqueta, un botn o un cuadro de texto), existen controles muy complejos que sera
difcil recrear desde cero con HTML y JavaScript. Por ejemplo el control calendario, las rejillas de datos, los
controles maestro-detalle, validadores, etc...
2005 24
Sus mtodos y propiedades tienen nombres consistentes con el resto de la plataforma. Por ejemplo, para fijar
el texto de un botn o de una etiqueta se usa la misma propiedad Text. Para establecer el color de fondo
todos usan BackColor. Esto hace que sea ms fcil el desarrollo porque no hay que memorizar
nomenclaturas diferentes para cada control.
3.2.1.- Adaptacin automtica al cliente
Los controles Web que vienen con ASP.NET tienen otra caracterstica que los hace nicos y es la adaptacin
automtica 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 autnoma adapta el cdigo que muestra a
las capacidades y restricciones concretas del navegador utilizado.
Esta adaptacin tiene en cuenta el soporte de HTML y JavaScript, pero tambin cuestiones como si se deben
usar etiquetas bsicas en lugar de hojas de estilo CSS para el aspecto.
En esta nueva versin 2.0 de ASP.NET va un paso ms all permitiendo la adaptacin automtica de los
controles a diferentes navegadores y dispositivos incluso mviles (telfonos y PDA de cualquier marca). A
esta caracterstica se la conoce como renderizacin adaptativa.
Figura 3.3.- Renderizacin adaptativa: un mismo calendario en un navegador y visto desde un mvil
WAP.
La renderizacin adaptativa tiene implicaciones importantes ya que (hasta cierto punto) no hay que tener en
cuenta de antemano si un desarrollo ser para un navegador concreto o incluso para dispositivos mviles
basados en WAP. Por otra parte, y tal vez ms importante, est el hecho de que no hay que aprender todo un
conjunto diferente de habilidades para poder programar para dispositivos mviles. Podemos reutilizar lo que
estamos aprendiendo en este libro!.
Nota Importante:
Si est utilizando la Beta 2 de la plataforma .NET sta todava no incluye los adaptadores que permiten la
transformacin adecuada para dispositivos mviles. Es de esperar que la versin definitiva s los incluya, al
igual que anteriores betas. Existe una nueva versin (la 1.1) de los controles especficos para desarrollo dirigido
a dispositivos mviles que podemos utilizar de la manera tradicional desde Visual Web Developer Express
2005, aunque ello se sale del mbito de este libro.
Si intenta ejecutar el ejemplo de la figura anterior con una pgina Web normal obtendr un error en el
dispositivo mvil. Para conseguir que funcione deber escribir usted mismo un adaptador para el dispositivo
en cuestin. He incluido la figura como prueba de concepto.
La siguiente figura muestra la jerarqua de algunos controles Web de servidor incluidos con ASP.NET 2.0:
2005 25
Figura 3.4.- Jerarqua de controles Web de servidor.
3.2.2.- Controles de terceras empresas
Aparte de los controles que vienen con ASP.NET 2.0 tambin es posible utilizar desde nuestras aplicaciones
cualquier otro control Web diseado por terceras empresas. Existen infinidad de ellos de todos los tipos,
algunos realmente potentes.
Figura 3.5.- Algunos ejemplos de controles Web de terceras empresas.
2005 26
En www.asp.net/controlgallery/ podr encontrar un extenso catlogo clasificado de controles Web de

servidor.
3.2.3.- Controles propios
Como no podra 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.
Existen dos tipos de controles que podremos crear:

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 reutilizacin de partes completas de la interfaz de usuario y de la
lgica asociada a sta, aunque el soporte para configurarlos en tiempo de diseo es mucho ms
reducido que en el caso de los anteriores. Sin embargo son muy fciles de crear y ofrecen un mtodo
sencillo de encapsular funcionalidades que incluyan interfaz de usuario.
La creacin de controles Web (primer tipo) es una cuestin compleja que se sale del mbito de este libro, por
lo que no los estudiaremos. Sin embargo en el siguiente apartado veremos la forma de crear nuestros propios
controles de usuario.
Investigue por su cuenta la funcionalidad de algunos de los controles disponibles en ASP.NET. Es la mejor
forma de aprender. Descubrir que la mayora son muy fciles de utilizar y sus propiedades y mtodos son de
uso sencillo. Deje de momento los enlazados a datos pues sern objeto de un captulo posterior y suelen tener
ms complicacin.
3.3.- Controles Web de validacin
Dentro de la pltora de controles de ASP.NET existe un grupo "Validacin" que, como es fcil imaginarse,
contiene una serie de controles que permiten realizar de manera cmoda la validacin de datos introducidos
por los usuarios.
Lo habitual en las aplicaciones Web es realizar una doble

validacin.
Por un lado se suele implementar una primera validacin en el

cliente (es decir, en el navegador de los usuarios) utilizando
para ello cdigo JavaScript. Esto permite una primera barrera
que no implica el envo de datos innecesarios al servidor.
Como principales desventajas de usar JavaScript para la
validacin se encuentran la de ser cdigo tedioso de escribir y,
sobre todo, que es muy fcil evitarla. Bastara con que un
usuario no tuviese JavaScript habilitado para que no funcionara
en absoluto.
Por otra parte tambin se suele realizar una segunda comprobacin en el servidor. En aras de la seguridad,
como mxima de cualquier desarrollo deberamos tomar siempre la siguiente: "Jams deber fiarme de nada que me
llegue de un origen fuera de mi control". En este caso aunque hayamos habilitado una primera validacin 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 validacin que sea siempre la del cliente.
Esta doble validacin suele ser bastante engorrosa y supone un esfuerzo de desarrollo adicional que sera
estupendo poder obviar. Pensando en facilitarnos este tipo de tareas ASP.NET nos ofrece los controles de
validacin.
2005 27
Estos controles permiten definir reglas de validacin 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 mltiples
restricciones sobre los datos introducidos.
Las condiciones tpicas son, por ejemplo, que un campo no se puede quedar vaco, que tiene que estar
comprendido dentro de un rango determinado o incluso que debe cumplir con una expresin regular que
indiquemos. Por supuesto es posible tambin definir reglas propias personalizadas.
La principal ventaja de estos controles es que permiten la definicin de reglas de validacin de forma
declarativa, es decir, no hace falta escribir cdigo para usarlos. Ello facilita mucho el desarrollo y el
mantenimiento de las reglas de validacin.
Una vez que definamos las reglas para un formulario los controles de validacin se encargan automticamente
de validarlas tanto en el cliente como en el servidor. En el lado cliente se convertirn en cdigo JavaScript
muy parecido al que nosotros usaramos, 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 validacin en el lado del cliente de un control estableciendo su propiedad
EnableClientScript a False. Podemos deshabilitar la validacin del lado cliente de todos los controles
estableciendo la propiedad ClientTarget de la pgina actual con la cadena "DownLevel" desde el evento de
carga de la pgina. Con ello slo se realizar la validacin en el servidor.
3.3.1.- Uso de los controles de validacin
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
tendrn si se hace necesaria su actuacin. Mientras no se produce una situacin en la que la validacin fracasa
sern invisibles. Toda esta funcionalidad se consigue utilizando JavaScript, es decir, que no se enva nada al
servidor (no se hace un post-back).
Pruebe usted mismo los controles descritos en este apartado para comprobar su funcionamiento. Ver que le
resultar muy fcil.
Cada control de validacin 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
validacin.
Aunque su utilidad es bastante intuitiva, la siguiente tabla indica el uso apropiado de cada uno de los controles
disponibles:
Control Utilidad
RequiredFiledValidator Verifica que el control asociado no se
encuentra vaco.
RangeValidator Genera un mensaje de error cuando el
contenido de su control asociado est fuera de
un rango de valores dado. Permite validar
intervalos numricos (enteros o decimales o
monedas), fechas y cadenas de texto.
RegularExpressionValidator Compara un texto introducido por el usuario
con una expresin 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 lgica de validacin
2005 28
propia tanto en el cliente como en el servidor.
Tabla 3.1.- Controles de validacin y su utilidad.
El control ValidationSummary (abajo de todo en el grupo de controles de la figura anterior) se usa para
mostrar un resumen de todo lo que est mal en un formulario en lugar de mostrar cada uno de los mensajes
de error individualmente.
No todos los controles se pueden validar con los controles de validacin. De hecho slo un pequeo
subconjunto de todos los controles Web son adecuados para un uso combinado. En cualquier caso los
incluidos cubren la mayor parte de las necesidades normales de introduccin de datos, y son los siguientes:
Control Tipo Propiedad

HtmlinputText Entrada de texto Value
HtmlTextArea Entrada de texto Value
TextBox Entrada de texto Text
HtmlSelect Lista de seleccin Value
ListBox Lista de seleccin SelectedItem.Value
DropDownList Lista de seleccin SelectedItem.Value
RadioButtonList Botones de seleccin SelectedItem.Value
HtmlInputFile Envo de archivos Value
Figura 3.2.- Controles que se pueden validar y las propiedades que se validan en ellos.
Aparte de mostrar la informacin de error al usuario, en los eventos de la pgina gestionados en el servidor
podemos comprobar el valor de la propiedad IsValid del objeto Page. sta ser False si alguno de los
controles de validacin ubicados en la pgina no ha pasado la prueba de verificacin. Esto es muy til para
realizar acciones complementarias en el servidor en caso de haber errores.
Sabiendo todo esto es fcil utilizar cualquiera de los controles de este tipo. Practique usted mismo con Visual
Web Developer 2005 Express.
3.3.2.- Colocar el foco en el error
Una accin muy comn a la hora de validar datos en un formulario es colocar el foco sobre el control que
contiene informacin errnea. De este modo se facilita al usuario la introduccin del nuevo valor pues no
tiene que activar el control con el ratn. Podemos hacer que los controles de validacin hagan esto por
nosotros con slo establecer a True su propiedad SetFocusOnError. Esta caracterstica es nueva en
ASP.NET 2.0.
3.4.- Controles de usuario
Como ya hemos adelantado en el apartado anterior, aparte de la compleja creacin de controles Web
personalizados del estilo de los que vienen con ASP.NET, existe una forma rpida y sencilla de reutilizar
partes completas de funcionalidad e interfaz de usuario. Para ello no es necesario tener profundos
conocimientos de la plataforma .NET. Ni siquiera hacen falta conocimientos de HTML. Se trata de los
controles de usuario. En este epgrafe veremos qu son, cmo se crean y cmo se utilizan.
Los controles de usuario son tan fciles 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 diseador visual idntico
que permite arrastrar otros controles sobre su superficie. De hecho cualquier formulario Web (pgina ASPX)
puede transformarse directamente en un control reutilizable con slo unos pocos cambios de sintaxis.
2005 29
Para aadir un nuevo control de usuario pulse con el botn derecho sobre el nodo raz del proyecto en el
explorador de soluciones y escoja la opcin "Agregar elemento...". En el dilogo que aparece (ya sobradamente
conocido) seleccione el icono correspondiente a Control de usuario Web, como se ilustra en la siguiente
figura:
Figura 3.7.- Dilogo para aadir un nuevo control de usuario.
Si se fija en la figura detenidamente ver que, salvo por el icono elegido, no hay diferencia alguna con aadir
un nuevo formulario Web. De hecho la nica diferencia existente en este punto es la extensin que se le
otorgar al archivo resultante, que es .ascx en lugar de .aspx.
El archivo resultante se distingue fcilmente en el explorador de

proyectos porque VWD le asigna un icono diferente (vea la figura
lateral).
Al igual que un formulario Web corriente, un control de usuario

dispone de un diseador visual con doble vista (Diseo y Origen) y de
un editor de cdigo asociado en caso de haber escogido la
separacin de cdigo e interfaz (opcin marcada en la figura
anterior).
Del mismo modo estn disponibles para arrastrar sobre la superficie

de diseo los mismos controles web que en el caso de los
formularios Web.
La primera diferencia con una pgina 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:
2005 30
Figura 3.8.- Cdigo origen de un control de usuario sobre el que se han arrastrado tres controles
Web.
Otra diferencia fundamental de un control con una pgina 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 caractersticas en comn.
Figura 3.9.- Cdigo de la clase code-beside de un control de usuario. en el que se ve que sta hereda
de UserControl .
De hecho la similitud es tal que el entorno de desarrollo le asigna al manejador del evento Load del control el
nombre Page_Load (en lugar de, por ejemplo, UserControl_Load) como se observa en la figura.
3.4.1.- Definicin de la funcionalidad pblica del control de usuario
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 ms que una clase de .NET, podemos extenderla
aadindole nuestros propios mtodos y propiedades. Todos los miembros pblicos que agreguemos estarn
disponibles desde la pgina que albergue al control del mismo modo que lo estn las propiedades y mtodos
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 vern adecuadamente en la pgina
que lo contenga y se comportarn del modo esperado, esto es, recibiendo eventos, conservando su estado en
el ViewState, etc...
3.4.2.- Uso de los controles de usuario
Ahora que ya sabemos crear controles de usuario veamos la forma de usarlos desde los formularios Web.
2005 31
El modo ms sencillo de incluir un control de usuario en una pgina ASPX es simplemente arrastrndolo
desde el explorador de proyectos sobre su superficie de diseo. Esto har que se visualice el control completo
dentro de la pgina:
Figura 3.10.- Control de usuario arrastrado sobre la superficie de un formulario Web (los puntos
rojos se usan para destacarlo, no estaban en la imagen original).
Nota:
Visual Web Developer 2005 ofrece un mayor soporte en tiempo de diseo 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 vea de estos controles era un cuadro de color gris
con su nombre y eran por tanto ms difcil trabajar con ellos y encajarlos en un diseo general.
Cuando observamos el cdigo de la pgina ASPX desde la que estamos utilizando el control de usuario,
vemos que al principio de sta se ha incluido una directiva Register:
Quiz el atributo ms 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 pgina. De este modo se pueden
utilizar sin problemas controles de usuario con el mismo nombre en una misma pgina. As, segn la lnea
anterior podramos definir en la pgina 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 lnea anterior, por ejemplo) siempre que se trate de tipos simples.
Podemos modificar la directiva Register para incluir un prefijo que nos guste ms o sea ms descriptivo que
el que VWD ha puesto por defecto.
2005 32
CAPTULO 4
TCNICAS DE TRABAJO Y
CONSEJOS VARIOS
ESTE BREVE CAPTULO DESCRIBE ALGUNAS CUESTIONES MISCELNEAS QUE LE
AYUDARN EN SU TRABAJO CON PGINAS .ASPX.
4.1.- Navegacin entre pginas
Antes de nada me parece necesario comentar que en las aplicaciones ASP.NET se utilizan seguramente
muchas menos pginas que en el caso de que la misma aplicacin estuviese escrita con ASP clsico. Esto se
debe a que, gracias a los post-back y los correspondientes eventos de servidor se encapsula ms la
funcionalidad en un slo archivo.
Por ejemplo en una aplicacin ASP 3.0 clsica para recoger los datos de un usuario con mucha probabilidad
escribiramos dos (o incluso tres o cuatro) pginas: la pgina HTML con el formulario, la pgina ASP a la que
se envan los datos del formulario y puede que una pgina o dos para informar al usuario del xito o del
fracaso de su accin. En ASP.NET todo esto se resolvera con una sola pgina ASPX, un evento de servidor
y probablemente mostrando y ocultando controles Web desde dicho evento.
Por supuesto una aplicacin estar formada de todos modos por un nmero ms o menos elevado de pginas
a las que se debe dirigir al usuario. Existen diversas maneras de dirigir a un usuario hacia otra pgina o recurso
de la aplicacin.
4.1.1.- Enlaces
La primera de ellas, y la ms sencilla, consiste en utilizar controles del tipo HyperLink que tiene este aspecto
en el cuadro de herramientas:
.
Estableciendo su propiedad NavigateUrl estaremos indicando a qu pgina queremos enviar al usuario
cuando pulse sobre el enlace resultante. Si la pgina es una de las que pertenecen a nuestra aplicacin ser
muy fcil seleccionarla gracias al dilogo especial que aparece para ello:
Figura 4.1.- Dilogo de seleccin de pginas de nuestra aplicacin.
2005 33
Adems si ajustamos la propiedad Text de este control ese ser el texto que se muestre para el enlace de la
pgina. Es posible utilizar un grfico en lugar de texto para el enlace si se utiliza la propiedad ImageUrl.
Nota:
Existen controles especializados en crear rboles de navegacin en una pgina pero por debajo usan enlaces
como estos.
4.1.2.- Redireccin
La otra manera de enviar a los usuarios a una pgina propia o ajena consiste en hacer uso del mtodo
Redirect de la clase HttpResponse del contexto de llamada de la pgina. As podremos controlar desde un
evento de servidor a dnde enviaremos al usuario. Por ejemplo, si queremos enviarlo a una pgina diferente
segn lo que haya escogido en un control de seleccin podramos escribir algo similar a esto en el evento de
pulsacin de un botn:
If opciones.ListIndex = 0 Then
Response.Redirect("opcion1.aspx")
Else
Response.Redirect("opcion2.aspx")
End If
El mtodo Redirect enva al navegador del usuario una cabecera especial de redireccin que le indica que, en
lugar de descargar los contenidos de la pgina actual, debe solicitar una nueva. Esto provoca una nueva
peticin de pgina desde el navegador por lo que no es la forma de navegacin de mayor rendimiento (hay el
doble de viajes al servidor que en un enlace directo). Sin embargo dota de gran flexibilidad a la hora de decidir
qu hacer ante la solicitud de pgina de un usuario o para redirigir al final de un proceso ejecutado en el
servidor.
4.2.- Envo de datos entre pginas
Como hemos visto el comportamiento normal durante la pulsacin de un botn u otro evento de controles
servidor es el de realizar un post-back a la pgina actual. Sin embargo puede haber ocasiones en las que, por el
motivo que sea, se necesita realizar ese envo de datos a otra pgina diferente, pero eso s, conservando el
acceso a todos los controles y datos de la pgina original (que como sabemos estn contenidos en el
ViewState).
ASP.NET 2.0 ha aadido 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 pgina asignndole la ruta virtual de sta ltima.
Los datos se reciben en la otra pgina pero todava tenemos acceso a los datos de la pgina original a travs
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 genrico, tendremos que utilizar el mtodo FindControl de la clase Page para
localizar cualquier control que hubiese en la pgina original. Por supuesto si ambas pginas pertenecen al
mismo espacio de nombres (o lo hemos declarado) podemos forzar el uso de la pgina como la clase original
de sta usando CType y acceder directamente a sus mtodos, propiedades y controles.
Tambin es posible determinar desde una pgina si los datos que est recibiendo son de su propio Post-back
o pertenece a otra pgina mediante la propiedad IsCrossPagePostBack, que es muy similar a la propiedad
IsPostBack que ya hemos estudiado.
Esta tcnica es de un uso poco frecuente pero se trata de una novedad poco conocida que me ha parecido
interesante incluir aqu.
2005 34
4.3.- Transferir el control entre pginas
A veces puede ser til procesar el cdigo de una pgina y justo despus transferir el control a otra pgina
ejecutando tambin su cdigo. El mtodo Transfer de la clase HttpServer ejecuta dinmicamente el cdigo
de una pgina desde otra cualquiera.
La forma de hacerlo es la siguiente:
Server.Transfer("otrapagina.aspx")
Al contrario que el uso de Redirect, Server.Transfer no cambia la URL que el usuario ve en su navegador
ya que desde fuera no se observa ninguna variacin en la pgina ejecutada. Es una ejecucin en el servidor,
sin redireccin en el cliente.
Este mtodo es anlogo al del mismo nombre en ASP clsico, si bien en ASP.NET su utilidad es menor
puesto que, como veremos, existen maneras mucho mejores y ms recomendables de reutilizar cdigo de uso
comn en las pginas.
4.4.- Reutilizacin de cdigo en una aplicacin
A menudo, al escribir una aplicacin, tenemos necesidades similares en diversas partes de sta. Por ello sera
absurdo escribir una y otra vez el mismo cdigo dentro de los manejadores, al cargar una pgina y dems
eventos. Lo mejor es encapsular el cdigo en diversos mtodos y llamar a stos cuando sea necesario. Todo
esto sonar de perogrullo a cualquier programador experimentado.
En ASP clsico, por ejemplo, se solan agrupar las funciones de uso comn dentro de archivos de inclusin
que luego se utilizaban en las diferentes pginas gracias a una directiva . Si bien esto
constitua una manera bsica de reutilizar cdigo no ofreca la flexibilidad de un lenguaje capaz de crear
bibliotecas de objetos y mtodos.
En .NET es posible crear nuevas clases que encapsulen funcionalidades comunes y que sean reutilizables en
cualquier punto de la aplicacin. Si bien la versin Express de Visual Web Developer nos limita un poco a la
hora de crear bibliotecas DLL de funcionalidad comn que se puedan usar incluso en otras aplicaciones, s
ofrece maneras alternativas de organizacin y reutilizacin del cdigo. Se trata de algo sencillo pero que
merece una explicacin aparte o sera fcil que pasara inadvertido.
En ASP.NET 2.0 existen una serie de carpetas con nombres especiales que cuelgan de la carpeta principal de
la aplicacin y que llevan asociado un comportamiento especial. Una de estas carpetas es 'App_Code'.
Bsicamente, todo el cdigo que se coloque bajo esta carpeta App_Code se compila de manera
automtica.
Tal y como hemos estudiado anteriormente, cuando se solicita una pgina sta se compila de manera
automtica junto con su archivo de "code-beside" de forma que, a medida que se accede a las diferentes
partes de una aplicacin se va compilando por completo. Dadas las caractersticas de VWD Express, el
cdigo residente en archivos que no sean pginas o clases parciales de "code-beside" no se compila ya que
jams navegamos por l ni se referencia desde otras pginas. La excepcin a esta regla es el cdigo que
coloquemos en la carpeta App_Code que se compila automticamente al comenzar la aplicacin.
Nota:
En la versin completa de Visual studio 2005 no tenemos estos problemas ya que podemos generar bibliotecas
DLL que encierren cualquier funcionalidad para su reutilizacin.
Por ello, la mejor forma de reutilizar cdigo en VWD Express es agregar clases especializadas a la carpeta
App_Code. De hecho si pulsamos con el botn derecho 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 aadirla a App_Code si queremos que funcione. Incluso se crea automticamente la carpeta si no lo
hemos hecho ya con anterioridad:
2005 35
Figura 4.2.- Advertencia para colocar cdigo en App_Code.
Incluso si intentamos agregar un nuevo elemento a la carpeta App_Code slo se nos ofrecer la posibilidad de
incluir nuevas clases, archivos de texto (para comentarios, por ejemplo) u objetos DataSet. Estos ltimos son
DataSet tipados que no dejan de ser clases con un diseador asociado como veremos en el siguiente captulo.
Una vez creadas nuevas clases en estas carpeta podemos aadirle mtodos, 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 mdulos o espacios de nombres para ordenarlas.
2005 36
CAPTULO 5
ACCESO A DATOS CON ADO.NET

SIN LUGAR A DUDAS UNO DE LOS MBITOS MS IMPORTANTES DE UN LENGUAJE O
ENTORNO DE PROGRAMACIN ES SU CAPACIDAD DE ACCESO A DATOS.
PRCTICAMENTE TODAS LAS APLICACIONES CONLLEVAN LA REALIZACIN DE
ACCESOS A DATOS.
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 GENRICO DE ADO.NET. LOS CONOCIMIENTOS ADQUIRIDOS EN
ESTE CAPTULO LE SERVIRN PARA CUALQUIER TIPO DE DESARROLLO CON .NET,
NO SLO PARA APLICACIONES WEB. LOS CONCEPTOS EXPLICADOS SON VLIDOS
TAMBIN PARA CUALQUIER VERSIN DE .NET, NO SLO PARA LA 2.0.
Nota:
No se deje engaar 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
crame cuando le digo que es mejor que se olvide para siempre de todos ellos. Tanto la filosofa de trabajo
como la tecnologa son diferentes por completo y es mejor que utilice una estrategia de "ojos limpios" para
acercarse correctamente a la nueva tecnologa.
Como cualquier otro modelo de acceso a datos, ADO.NET es un conjunto de clases relacionadas entre s que
estn especializadas en ofrecer toda la funcionalidad que un programador necesita para realizar acceso a datos
y manejarlos una vez los ha obtenido. Las clases genricas expuestas por ADO.NET se encuentran bajo el
espacio de nombres System.Data. Este espacio de nombres define clases genricas de acceso a datos que
posteriormente son extendidas para ofrecer caractersticas y funciones especficas de cada proveedor.
El objeto ms importante a la hora de trabajar con el nuevo modelo de acceso a datos es el DataSet. Sin
exagerar demasiado podramos calificarlo casi como un motor de datos relacionales en memoria. Aunque hay
quien lo asimila a los clsicos Recordsets su funcionalidad va mucho ms all como se ver en breve.
5.1.- Conceptos fundamentales de ADO.NET
La cuestin ms importante que hay que tener claro sobre ADO.NET es su modo de funcionar, que se revela
claramente al analizar su arquitectura, que tal vez recuerde del primer captulo:
Figura 5.1.- Arquitectura de ADO.NET
2005 37
Existen dos capas fundamentales dentro de su arquitectura: la capa conectada y la desconectada.
5.1.1.- La capa conectada
La capa conectada de ADO.NET contiene objetos especializados en la conexin con los orgenes de datos.
As, la clase genrica Connection se utiliza para establecer conexiones a los orgenes de datos. La clase
Command se encarga de enviar comandos de toda ndole al origen de datos. Por fin la clase DataReader
est especializada en leer los resultados de los comandos.
La clase DataAdapter hace uso de las tres anteriores para actuar de puente entre la capa conectada y la
desconectada como veremos despus.
Estas clases son abstractas, es decir, no tienen una implementacin 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, adems de otras particularidades
que se deben contemplar. Un proveedor de datos de ADO.NET es una implementacin concreta de estas
clases conectadas abstractas que acabamos de mencionar, que hereda de stas y que tiene en cuenta ya todas
las particularidades del origen de datos en cuestin.
As, por ejemplo, las clases especficas 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 clsico no hay una nica clase Connection o Command que se use en cada caso,
si no que existen clases especializadas para conectarse y recuperar informacin 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
cdigo independiente del origen de datos. Todo lo contrario. La plataforma .NET ofrece facilidades de escritura
de cdigo genrico basadas en el uso de herencia e implementacin de interfaces. De hecho la versin 2.0 de
.NET ofrece grandes novedades especficamente 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 travs de
ODBC u OLEDB cuando no existe un proveedor nativo para un determinado origen de datos. Los
proveedores puente, si bien muy tiles en determinadas circunstancias, ofrecen un rendimiento menor debido
a la capa intermedia que estn utilizando (ODBC u OLEDB). Un programador novel puede sentir la
tentacin de utilizar siempre el proveedor puente para OLEDB y as escribir cdigo 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.
La plataforma .NET proporciona "de serie" los siguientes proveedores de acceso a datos:
Proveedor Espacio de nombres

Descripcin
ODBC .NET Data Provider Permite conectar nuestras aplicaciones a
System.Data.Odbc
fuentes de datos a travs de ODBC.
OLE DB .NET Data System.Data.OleDb Realiza la conexin utilizando un
Provider proveedor OLEDB, al igual que el
ADO clsico.
Oracle Client .NET Data System.Data.OracleClient Proveedor de datos para acceder a
Provider Oracle.
SQL Server .NET Data System.Data.SqlClient Permite la conexin optimizada a SQL
Provider Server 7.0 o posterior, incluyenbdo la
ltima versin SQL Server 2005.
Los proveedores de acceso a datos que distribuye Microsoft en ADO.NET y algunos desarrollados por otras
empresas o terceros, contienen los mismos objetos, aunque los nombres de stos, sus propiedades y mtodos,
pueden ser diferentes.
2005 38
Existen, por supuesto, proveedores para otros tipos de orgenes de datos como AS/400, MySQL, FireBird, y
en general cualquier gestor de datos existente en el mercado. stos los desarrolla normalmente la empresa
responsable del producto. Si bien stos optimizan el acceso a estos orgenes de datos nosotros siempre
podremos realizarlo mediante ODBC u OLEDB si tenemos necesidad.
En resumen: con la capa conectada de ADO.NET realizamos la conexin y comunicacin con los orgenes
de datos. Cada proveedor de datos implementa su propia versin de las clases Connection, Command, DataReader
y DataAdapter (entre otras).
Las clases derivadas de Connection se utilizan para realizar la conexin y enviar y recibir
informacin.
Las clases derivadas de Command permiten ejecutar sentencias SQL y procedimientos almacenados
en el gestor de datos.
Las clases derivadas de DataReader se emplean para obtener los posibles resultados de un comando
utilizando para ello el conducto de comunicacin establecido por Connection.
5.1.2.- La capa desconectada
Una vez que ya se han recuperado los datos desde un origen de datos la conexin a ste ya no es necesaria.
Sin embargo sigue siendo preciso trabajar con los datos obtenidos de una manera flexible. Es aqu cuando la
capa de datos desconectada entra en juego. Adems, 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 conexin. A veces
nicamente necesitamos un almacn de datos temporal pero que ofrezca caractersticas avanzadas de gestin
y acceso a la informacin.
Por otra parte las conexiones con las bases de datos son uno de los recursos ms escasos con los que
contamos al desarrollar. Su mala utilizacin es la causa ms frecuente de cuellos de botella en las aplicaciones
y de que stas no escalen como es debido. Esta afirmacin es especialmente importante en las aplicaciones
Web en las que se pueden recibir muchas solicitudes simultneas 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 informacin entre capas de una aplicacin. stas pueden encontrarse distribuidas por
diferentes equipos, e incluso en diferentes lugares del mundo gracias a Internet. Por ello es necesario disponer
de algn modo genrico 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 la
informacin con el origen de datos del que proceden. Todo esto y mucho ms es lo que nos otorga el uso de
los objetos DataSet, ncleo central de la capa desconectada de ADO.NET.
Otra interesante caracterstica de los DataSet es que permiten gestionar simultneamente 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 tcnica avanzada que consiste en crear tipos nuevos de DataSet especializados en la gestin de una
informacin concreta (por ejemplo un conjunto de tablas relacionadas). Estas nuevas clases se denominan
genricamente DataSet Tipados, y permiten el acceso mucho ms cmodo a los datos que representan,
verificando reglas de negocio, y validaciones de tipos de datos ms estrictas.
Los objetos DataSet no dependen de proveedor de datos alguno y su funcionamiento es independiente de

cmo hayan sido obtenidos los datos que contienen. Este es el concepto ms importante que debemos
recordar.
El proceso general de trabajo de ADO.NET para acceder a un gestor de datos (SQL Server, por ejemplo) es
casi siempre el mismo: se abre una conexin (clase Connection), se lanza una consulta SQL o procedimiento
almacenado mediante un objeto de la clase Command, y se almacenan en memoria los resultados dentro de un
objeto DataSet, cerrando la conexin.
2005 39
Nota:
Aunque este es el comportamiento habitual de una aplicacin 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 informacin, tratarla y no almacenarla en lugar alguno. De todos modos lo ms
frecuente es realizar el proceso descrito.
5.1.3.- Unin entre capa conectada y desconectada
La clase DataAdapter se ha incluido anteriormente en la capa conectada por que est implementada por cada
proveedor de un modo diferente. En realidad es una clase que pone sus pies en ambos mundos (conectado y
sin conexin) y sirve de nexo entre ellos.
Un DataAdapter sabe como manejar correctamente los objetos proporcionados por su proveedor especfico
(fundamentalmente los vistos: Connection, Command y DataReader) y proporciona mtodos para trasegar
informacin desde el servidor a instancias desconectadas de DataSet y viceversa haciendo uso de dichos
objetos especficos del proveedor.
As, por ejemplo, el mtodo Fill de un DataAdapter se utiliza para introducir los resultados de una consulta
dentro de un DataSet para luego trabajar con ellos sin preocuparnos de su origen. Del mismo modo su
mtodo Update se utiliza para conciliar automticamente con el origen de datos los datos modificados en un
DataSet mientras no haba conexin.
5.1.4.- Otras clases dependientes de DataSet
Como hemos dicho antes un DataSet podra asimilarse a un pequeo gestor de datos en memoria. Como tal
permite mantener diversas tablas as como las relaciones entre ellas, incluso forzando que se cumplan
restricciones de creacin y actualizacin, como en una base de datos "real". Para ello se apoya en el uso de
otras clases especializadas que son las siguientes:
DataTable: representa una tabla o relacin de datos. Se puede asimilar a una tabla de un gestor de
datos. Los datos obtenidos de una consulta de tipo SELECT de SQL se almacenan en un objeto de
esta clase.
DataColumn: ofrece informacin sobre cada uno de los campos de los registros almacenados en un
DataTable, como su nombre o su tipo.
DataRow: representa un registro de la tabla virtual definida por el DataTable. Contiene tantos
elementos como campos tiene la tabla, cada uno del tipo definido por el objeto DataColumn
correspondiente.
Constraint: las clases Constraint se emplean para definir restricciones en los tipos de datos
contenidos en un DataTable. Por ejemplo se puede usar un objeto de esta clase para indicar que un
determinado campo debe ser nico o que se trata de una clave externa que debe ser tenida en cuenta
en actualizaciones o borrados en cascada.
DataRelations: define la relacin existente entre dos objetos DataTable. Normalmente se suelen
utilizar un identificador comn a ambas tablas aunque pueden ser combinaciones de ms de uno de
ellos. De este modo se sabe cmo obtener informacin de una tabla a partir de informacin en otra.
Por ejemplo el identificador de una factura (su nmero, por ejemplo) puede servir para relacionar su
registro con los registros de detalle de factura que estn contenidos en otra tabla.
DataView: representa una vista concreta de un DataTable. Normalmente se trata de ordenaciones o
filtros sobre los datos originales. Todas las tablas disponen de una vista por defecto (propiedad
DefaultView) que ofrece los datos tal y como se han introducido en sta y es la vista que se usa
habitualmente.
5.1.5.- Vinculacin de datos a controles Web
2005 40
Otra caracterstica fundamental de ASP.NET que lo convierte en una herramienta ventajosa para el desarrollo
de aplicaciones Web es la capacidad de vincular datos a controles Web.
La mayor parte de los controles que podemos arrastrar sobre una pgina 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 edicin o navegacin si
hacemos un uso adecuado de la vinculacin y los controles disponibles.
Todo ello, gracias a ASP.NET y Visual Studio, equipara en muchos aspectos el desarrollo Web al clsico
desarrollo de aplicaciones de escritorio donde este tipo de facilidades han estado disponibles desde hace aos.
Sin embargo en una aplicacin Web donde no existe una conexin permanente disponible entre la
visualizacin (navegador) y el lugar en el que se ejecuta el cdigo no es algo fcil de conseguir. El uso de un
modelo consistente como ADO.NET (idntico en Web, escritorio y otros entornos) junto con las
capacidades nativas de ASP.NET para abstraernos de estas dificultades (ViewState, Postback...) consiguen el
"milagro". Ms adelante en este captulo veremos lo sencillo que resulta crear interfaces para explotar los
datos desde una pgina Web.
5.2.- Acceso a datos manual
Tras haber aprendido un poco de teora sobre ADO.NET a continuacin explicaremos cmo se utilizan las
clases de acceso datos para escribir cdigo de acceso a datos de manera manual. Si bien es un tema algo rido
y adems en un gran porcentaje de los casos utilizaremos herramientas que nos faciliten la creacin
automtica de cdigo, es fundamental conocer la forma de trabajar sin ayuda para entender el funcionamiento
real de los objetos de datos. Este es el espritu de este epgrafe. Le recomiendo que practique los ejemplos en
su propio equipo para asegurarse de que los ha entendido bien.
5.2.1.- Comandos de seleccin simples
La mayor parte de las consultas que se lanzan contra una base de datos se utilizan para obtener un conjunto
de registros para tratar. Este tipo de consultas suelen ser expresiones SQL de tipo SELECT. El siguiente
fragmento de cdigo muestra los pasos necesarios para visualizar en una pgina los registros resultantes de
una consulta:
No se trata de un cdigo optimizado (es ms 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 y que seguramente tendr en su ordenador instalada).
2005 41
Nota importante:
Para poder escribir cdigo de acceso a datos en nuestro mdulo debemos agregar referencias a los espacios
de nombres que contienen las clases que vamos a utilizar. Para ello usamos las dos sentencias Imports
siguientes:
La primera de ellas agrega las clases genricas de acceso a datos (como DataSet) y la siguiente las especficas
de SQL Server. Si no lo hacemos recibiremos un error.
Lo primero que se debe hacer es instanciar un objeto que represente la conexin a la base de datos. Dado que
nos estamos conectando a SQL Server esta conexin ser del tipo SqlConnection. Es lo que se hace en la
primera lnea del cdigo anterior. La conexin debe realizarse con un servidor de datos y un esquema de
datos concreto. Esto se indica mediante la cadena de conexin (al igual que se haca en ADO tradicional).
En este caso la cadena de conexin es la tpica de SQL Server. Cada gestor de datos tiene la suya y hay que
construirla de manera adecuada. El entorno de desarrollo VWD nos ayuda a crearlas como veremos luego.
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 en este caso un objeto SqlCommand. Las propiedades bsicas que hay que establecer para
ste son la consulta que se lanzar (propiedad CommandText) y la conexin que se emplear para lanzarla
(propiedad Connection) que es lo que se refleja en las lneas 6 y 7.
Ahora que ya sabemos cmo nos conectaremos y qu queremos obtener debemos lanzar la consulta y recoger
el resultado de alguna manera. La clase Command dispone de diversos mtodos para ejecutar consultas:
ExecuteReader: este mtodo lanza la consulta a la base de datos y devuelve una referencia a una
instancia de la clase DataReader (SqlDataReader en el caso de SQL Server). Podemos utilizar el
DataReader para recorrer los datos y procesarlos.
ExecuteNonQuery: ejecuta la consulta sin devolver resultado alguno. Simplemente enva la
consulta al servidor y devuelve el nmero de registros afectados por sta. til para realizar consultas
de insercin (INSERT), actualizacin (UPDATE) y borrado (DELETE).
ExecuteScalar: lanza la consulta y devuelve un objeto con el valor del primer campo del primer
registro que se obtenga de dicha consulta. Es til para lanzar consultas de agregacin como sumas
(SUM), cuentas (SELECT COUNT * ....) y similares de las que slo necesitamos un valor como
resultado.
En el ejemplo hemos utilizado el primer mtodo ya que requerimos que devuelva varios registros con
diferentes campos. Entonces lo que hacemos es (lneas a partir de la 9):
1. Abrir la conexin.
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. Fjese en que no se puede instanciar un DataReader (por eso
adems la declaracin no lleva la palabra clave New).
3. Se obtiene el resultado mediante el mtodo ExecuteReader, recogindolo en la variable (dr) recin
declarada.
4. Se procesan los resultados (lneas 14-18).
5. Se cierra la conexin.
El objeto DataReader es asimilable a un cursor de servidor de slo lectura y hacia adelante (conocidos como
de manguera de bombero o firehose). Es decir, los datos devueltos por el DataReader slo se pueden leer y no
actualizar. Adems de esto slo se pueden leer en secuencia hacia adelante (no hay forma de regresar sobre lo
andado).
La propiedad HasRows nos indica si hay o no resultados devueltos. El mtodo Read avanza una posicin en
los registros devolviendo True si quedan registros pendientes de leer. Con esta informacin es muy fcil
entender las lneas 14 a 18.
5.2.2.- La clusula Using
2005 42
Qu ocurre si se produce un error durante el procesamiento del bucle anterior en el que se trata el
DataReader?. La respuesta es que la conexin, que debemos tener abierta durante el procesamiento, no se
cerrar pues el cdigo no llega al final.
Esto es algo muy grave ya que las conexiones que no se cierran no se pueden reutilizar y por lo tanto puede
llegar un momento en que no tengamos conexiones disponibles, lo que limita enormemente la escalabilidad
del sistema.
Podemos evitar el problema escribiendo un gestor estructurado de excepciones:
De este modo, con la clusula Finally nos aseguramos que siempre se va a cerrar la conexin.
De todos modos escribir este cdigo es algo tedioso sobre todo si queremos que la excepcin se replique y
slo metemos la clusula Finally por el hecho de cerrar la conexin. Para facilitar el trabajo VB.NET en
.NET 2.0 incluye una clusula especial denominada Using que habilita la destruccin automtica de los
objetos a los que se hace referencia. As el cdigo anterior quedara simplemente:
Al terminar la clusula Using (aunque haya un error por medio) se llama de manera automtica al mtodo
Dispose del objeto utilizado (en este caso una conexin). Entre otras cosas este mtodo se encarga de cerrar
el objeto si estaba abierto, por lo que no nos tendremos que preocupar de este aspecto.
5.2.3.- Grupos de registros
Aunque los DataReader se asemejan al funcionamiento de un cursor firehose, en realidad difieren bastante de
stos. Imaginemos que conectamos con la base de datos en el ejemplo anterior y, mientras estamos
procesando el bucle de los registros, se interrumpe la conexin a la base de datos por el motivo que sea.
En principio en el caso de un cursor firehose tradicional obtendramos un error porque se ha roto la conexin
con el servidor. En el caso de un DataReader es posible que sigamos ejecutando varias vueltas ms del bucle
sin problemas. Esto se debe a que, en realidad, el DataReader obtiene los registros en grupos a travs de la
2005 43
conexin y va solicitando nuevos grupos a medida que los necesita. Es algo que hay que tener en cuenta a la
hora de utilizarlos.
5.2.4.- Ventajas e inconvenientes
El cdigo anterior, aunque sencillo, es un poco lioso y el uso de los DataReader est algo limitado dada su
idiosincrasia (de slo lectura y hacia adelante). Este cdigo es adecuado si no necesitamos almacenar los
resultados de la consulta en memoria ni regresar sobre ellos una vez procesados una primera vez. Tambin 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 cdigo muy poco til y complicado de utilizar salvo para
cosas muy sencillas. Adems slo hemos utilizado clases de la capa conectada de ADO.NET. Todava
debemos aprender a obtener los resultados dentro de un DataSet para su explotacin de manera cmoda. Hay
que tender un puente entre ambos mundos (conectado y desconectado): el DataAdapter.
5.3.- DataAdapter: puente entre mundos
Si lo que deseamos es poder almacena temporalmente en memoria los datos obtenidos de una consulta
debemos recurrir al uso de objetos de la clase DataSet. Como sabemos se trata de un almacenamiento en
memoria desvinculado por completo del origen de los datos.
Si el ejemplo anterior lo modificamos para convertirlo en una funcin que nos devuelva un DataSet con los
datos obtenidos a partir de la consulta, el resultado sera similar a este:
La primera parte del cdigo es como la anterior. Se crean una conexin y un comando. Lo que difiere
bastante es la segunda parte. Hay varias diferencias importantes:
1. Ya no aparece en el cdigo objeto DataReader de tipo alguno.

2. No se abre ni se cierra la conexin a la base de datos.
3. Se crea un nuevo DataSet y aparece un objeto de la clase DataAdapter.
Un DataAdapter es una clase que conoce las particularidades de la capa conectada de un determinado
proveedor y es capaz de "comunicar" informacin entre sta y la capa desconectada formada por los DataSet.
El mtodo Fill de un DataAdapter se encarga e rellenar un DataSet con los datos obtenidos a partir de una
consulta (o procedimiento almacenado) definida a travs de un comando. Su propiedad SelectCommand se
usa para indicar qu comando se utilizar para rellenar el DataSet.
2005 44
Internamente el mtodo Fill emplea el objeto DataReader devuelto por ExecuteReader y rellena el DataSet con
l por lo que sera factible crear un cdigo equivalente. Sin embargo es muy cmodo y nos evita problemas y
el tener que "reinventar la rueda" en cada proyecto.
5.3.1.- La clase 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 coleccin Tables. Se puede acceder a las tablas por posicin
(nmeros enteros) o por nombre si lo sabemos.
En un ejemplo sencillo como el anterior (y por otro lado uno de los ms comunes) se crea una nica tabla en
el DataSet de nombre "Table1" y posicin 0.
Las tablas contienen dos colecciones interesantes:

Columns: conjunto de objetos de tipo DataColumn que ofrecen informacin sobre los campos de
la tabla (nombre, tipo, longitud...).
Rows: coleccin de objetos de la clase DataRow que contienen informacin concreta sobre cada
campo de un registro de la base de datos.
Con esta informacin resulta muy sencillo tratar los datos de una consulta. Podemos acceder directamente a
cualquier registro de la tabla usando su posicin en la coleccin de filas. Por ejemplo para acceder al quinto
registro de una tabla basta con escribir (ntese que las colecciones comienzan a numerarse en 0, de ah que el
quinto registro tenga ndice 4):
Dim dr As DataRow
dr = ds.Tables(0).Rows(4)
Podemos acceder a cualquier campo del registro usando su posicin o bien su nombre, as:
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 mtodo Add de la coleccin Columns para crear nuevos campos, algunos de los
cuales pueden ser incluso derivados mediante una frmula 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.
5.3.2.- Ventajas del uso de objetos DataSet
Es posible cargar datos de varias tablas en un mismo DataSet, incluso aunque procedan de bases de datos
diferentes, y relacionarlas en memoria. Es posible establecer relaciones entre ellas para mantener la
consistencia, as como hacer un mantenimiento en memoria de los datos (altas, bajas y modificaciones).
Posteriormente se puede sincronizar el DataSet con el servidor usando un DataAdapter, realizando el proceso
contrario al de obtencin de datos. Luego lo veremos.
La principal ventaja de un DataSet es que podemos almacenarlo en donde queramos (en una variable global,
en cach, incluso a disco a una base de datos) para trabajar con l sin estar conectado a una base de datos. De
hecho se pueden transferir DataSet completos entre diferentes mquinas o por Internet, trabajar con ellos en
remoto, almacenarlos, recuperarlos y finalmente transferirlos en cualquier momento de nuevo al origen
(enteros o slo los cambios) para sincronizarlos.
5.4.- Consultas parametrizadas
2005 45
Las consultas simples como la que acabamos de utilizar en los ejemplos anteriores son muy raras. En la
realidad las consultas son mucho ms complejas, suelen intervenir varias tablas y dependen de diversos
parmetros que le aaden condiciones.
Por ejemplo, si en la base de datos Northwind queremos obtener slo aquellos clientes de un pas determinado.
Podramos escribir de nuevo la funcin DameClientes para que se pareciese a la siguiente:
Esta funcin acepta un pas como parmetro y lo nico que hace es concatenar a la consulta una nueva
condicin que introduce el pas.
Esto, sin duda, funcionara. Sin embargo presenta multitud de problemas seguramente no demasiado obvios
para los programadores noveles. Los ms importantes son los siguientes:
1. Este cdigo es vulnerable a problemas de seguridad provocados por ataques de inyeccin de

SQL. Esto puede poner en peligro fcilmente nuestra aplicacin e incluso todo nuestro sistema en
casos graves. El estudio de este tipo de problemas se sale del mbito de este libro, pero crame
cuando le digo que se trata de un gravsimo inconveniente que debemos evitar a toda costa.
2. Si se solicitan 100 consultas idnticas al servidor en las que slo vara el nombre del pas por el que
se filtra, ste no tiene modo de saber que son las mismas y sacar factor comn. Es decir, no se
puede reutilizar el plan de consulta de la primera de ellas para las dems por lo que se debe
calcular de nuevo cada vez, incidiendo en el rendimiento y la escalabilidad de la aplicacin.
Obviamente en consultas ms compllicadas es un problema ms importante que en esta.
3. Este cdigo es ms difcil de transportar a otros sistemas de bases de datos ya que hay que incluir los
delimitadores y notaciones especficos de cada gestor. Por ejemplo en SQL Server los delimitadores
de fechas son comillas simples ('), mientras que en Access son almohadillas (#) y la sentencia usada
no se puede reutilizar.
La forma correcta de realizar este tipo de consultas es utilizar parmetros en la consulta. Ello evita los
problemas enumerados.
Los objetos de tipo Command disponen de una coleccin llamada Parameters que sirve para asignar dichos
parmetros. stos previamente se definen en la consulta utilizando comodines que marquen su ubicacin.
Nota:
Cada proveedor de datos utiliza su propia convencin para indicar la posicin de los parmetros 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 parmetros, slo se marca su posicin con un caracter
especial.
La funcin anterior empleando parmetros sera la siguiente (se han resaltado los cambios):
2005 46
Como vemos en lugar de concatenar cadenas se marca la posicin de las partes de la consulta que varan con
un parmetro que consta de una arroba seguida de un identificador. Luego hay que declarar el parmetro
aadindolo a la coleccin de parmetros. Para ello se indica su nombre y el tipo de datos que representa (en
este caso un NVarChar de SQL Server, que es una cadena de longitud variable). Por fin se asigna su valor
concreto antes de lanzar la consulta.
El proveedor de datos crea la consulta de la manera correcta, usando los delimitadores adecuados y tratando
los datos del modo que sea preciso para asegurar que es correcta. Ello elimina los problemas de los que
hablbamos anteriormente y permite optimizar el uso de consultas.
5.5.- Altas, bajas y modificaciones
Con lo que hemos visto hasta ahora ya estamos en condiciones de escribir cdigo 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 funcin como la siguiente:
2005 47
Es un cdigo muy similar al anterior que realizaba una seleccin de datos. En este caso se ha definido una
consulta de insercin con tres parmetros. En lugar de usar ExecuteReader o un DataAdapter en este caso se
utiliza el mtodo ExecuteNonQuery. ste lanza la consulta (es decir, se inserta el nuevo registro) y devuelve el
nmero de registros afectados por la consulta (que en el caso de una insercin siempre es 1 si se inserta
correctamente o 0 si ha habido un error y lo captursemos).
Las actualizaciones y eliminaciones de registros se podran conseguir de modo similar.
5.5.1.- Trabajando desconectados
El cdigo anterior funciona perfectamente pero no es la forma ptima de trabajar cuando tenemos que tratar
con datos desconectados contenidos en objetos DataSet.
Los DataSet normalmente circulan, independientes de cualquier origen de datos, entre las diferentes capas de
una aplicacin e incluso se mueven entre contextos de ejecucin y mquinas (por ejemplo a travs de un
servicio Web como veremos). Hemos dicho que son como pequeas bases de datos, por lo que la forma
habitual de trabajar con ellos es aadir, eliminar y modificar registros directamente sobre sus tablas, sin pensar
en la ubicacin real de estos datos.
As pues, para crear un nuevo registro en un DataSet debemos usar el mtodo NewRow de la DataTable en la
que lo queremos insertar. El nuevo registro tiene la misma estructura (el mismo "esquema") que el resto de
registros y slo tendremos que rellenar sus datos. Una vez rellenados aadiremos el nuevo registro a la
coleccin de filas de la tabla. As por ejemplo si tenemos almacenado un DataSet con una tabla con los datos
de los clientes obtenidos con la funcin de ejemplo DameClientes, podramos agregar uno nuevo de la
siguiente manera:
2005 48
Es decir, se crea la nueva fila/registro, se rellenan sus campos y se aade a la coleccin de filas con el mtodo
Add de sta.
La actualizacin de datos es ms sencilla an ya que basta con acceder directamente al registro que nos
interesa modificar y cambiar los valores de sus campos. Por ejemplo, para modificar la direccin del cliente
cuyos datos estn en el quinto registro de nuestra tabla slo hay que escribir:
Por fin, para eliminar un registro slo hay que usar su mtodo Delete, as:
que borrara el quinto registro de nuestra tabla en memoria.
5.5.2.- Conciliando los cambios con el origen
Es muy fcil trabajar con los Dataset en memoria de este modo. Slo hay un "pequeo" 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.
Debemos realizar una sincronizacin entre la representacin en memoria de los datos y su ubicacin fsica
real, para lo cual debemos hacer que los cambios trasciendan a la capa conectada. Al igual que cuando los
recuperamos, el trasiego en el otro sentido se realiza con la ayuda del puente que representa la clase
DataAdapter.
Al igual que utilizbamos la propiedad SelectCommand para indicar cmo se recuperaban los datos hacia un
DataSet, ahora debemos utilizar las propiedades InsertCommand, UpdateCommand y DeleteCommand para
indicar qu comandos se deben usar para agregar, modificar y eliminar los registros modificados en memoria
a travs del DataSet.
Una vez especificados estos comandos slo resta llamar al mtodo Update del DataAdapter para que se ocupe
de sincronizar automticamente todos los cambios que hayamos realizado en las tablas en memoria. Este
mtodo acepta como argumentos un DataSet completo, una DataTable o incluso un DataRow si slo queremos
actualizar un nico registro.
5.5.3.- Definicin de los comandos
Los comandos de insercin, modificacin o borrado para el DataAdapter se definen del mismo modo que en
el cdigo de ejemplo al principio de este apartado, es decir, se define la consulta apropiada y sus parmetros.
En esta ocasin como los parmetros sern rellenados automticamente por el DataAdapter hay que utilizar
una sobrecarga del mtodo Add de la coleccin de parmetros que incluye el nombre del campo asociado con
el parmetro, as:
En este caso se define el parmetro "@Direccin", de tipo NVarChar y longitud 60 que se refiere siempre al
valor del campo "Address" de la tabla.
Por ejemplo, para definir la consulta de eliminacin de registros de la tabla de clientes usaramos el siguiente
cdigo:
2005 49
siendo CustomerID la clave primaria de la tabla.
Una vez definidos los tres parmetros de alta, baja y modificacin slo resta llamar a Update para que el
DataAdapter se ocupe de toda la sincronizacin.
5.5.4.- 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 Web Developer para definir de
manera automtica los comandos de manipulacin 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 conexin o no
con el origen y aunque el DataSet se manipule en una ubicacin fsica a miles de kilmetros del origen y
desconectado de ste o los cambios se almacenen a disco y se concilien das ms tarde.
Se pueden realizar multitud de modificaciones en los datos y luego conciliarlas simultneamente 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
parmetros como datos se quisieran modificar en un registro. Por ejemplo, para insertar un registro en una
tabla que tiene 20 campos se defina una funcin con 20 parmetros (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 informacin 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 algn tipo. El mtodo GetChanges de
los objetos DataSet y DataTable devuelve un subconjunto de los datos que contiene exclusivamente los
cambios. As, aunque en un DataSet tengamos 1.000 registros, si nicamente hemos modificado 2 slo ser
necesario trasegar la informacin de stos a la hora de enviarlos a otra capa o funcin para sincronizarlos con
la base de datos.
El mtodo GetChanges se puede invocar sin parmetros o indicando qu tipo de cambios queremos obtener,
lo que se indica con un valor de la enumeracin DataRowState:
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)
Se puede dejar un DataSet en estado sin modificar llamando a su mtodo AceptChanges. Esto es lo que hace
automticamente tambin un DataAdapter tras haber sincronizado los cambios con el origen de datos.
2005 50
CAPTULO 6
ACCESO A DATOS CON VISUAL

WEB DEVELOPER 2005
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 WEB DEVELOPER
QUE, COMO VEREMOS, NOS PERMITEN HACER CASI CUALQUIER TAREA DE DATOS
SIN NECESIDAD DE ESCRIBIR CDIGO.
6.1.- Controles de datos
Aparte de la escritura manual de cdigo y el uso directo de objetos

de ADO.NET, ASP.NET 2.0 proporciona un nuevo modelo de
trabajo declarativo para acceso a datos que nos permite realizar
tareas comunes de acceso a datos sin escribir cdigo alguno.
ASP.NET 2.0 presenta dos nuevos tipos de controles Web que

participan en este modelo declarativo de enlace a datos. Estos
controles nos abstraen por completo de las complejidades de
manejo de las clases de ADO.NET por un lado, y de las dificultades
inherentes al modo de trabajo desconectado de las pginas Web por
otro. Equiparan en muchos aspectos el desarrollo web al tradicional
desarrollo de aplicaciones de escritorio.
Estos controles se encuentran agrupados en el cuadro de

herramientas bajo el nombre de "Datos", tal y como se ve en la
figura.
6.2.- Orgenes de datos
Estos controles de datos representan conexiones con diferentes tipos de orgenes de informacin que van
desde bases de datos a objetos de negocio. No disponen de apariencia visual pero se arrastran igualmente
sobre los formularios Web para trabajar con ellos visualmente y poder usar sus paneles de tareas. Abstraen al
programador de las complejidades relacionadas con el manejo de los datos, permitiendo de manera
automtica seleccionarlos, actualizarlos, ordenarlos, paginarlos, etc..
ASP.NET 2.0 ofrece los siguientes controles de origen de datos que se pueden ver en la figura anterior
(abajo):
Control Descripcin
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 jerarqua de clases expuesta por el modelo de
navegacin de sitios de ASP.NET 2.0.
ATENCIN!: El control SqlDataSource sirve para enlazar con cualquier gestor de datos relacional para la que
haya proveedor ADO.NET disponible, no slo para enlazar con SQL Server. No se deje despistar por su nombre.
2005 51
6.3.- Controles enlazados a datos
Se trata de controles de interfaz de usuario que, haciendo uso de los anteriores, muestran la informacin a
travs de la pgina. Pueden sacar partido a todas las propiedades de los orgenes de datos y por lo tanto
habilitan de manera sencilla la edicin, eliminacin, ordenacin, filtrado y paginacin de los datos entre otras
cosas.
Para conectar un control enlazado a un DataSource slo hay que establecer su propiedad DataSourceID
indicando el nombre apropiado. As de fcil.
Nota:
Si usted ya conoce los controles enlazados a datos de ASP.NET 1.x como el DataGrid, el DataRepeater, etc...
estos controles le resultarn ms cmodos de utilizar pues al contrario que con aquellos no hay que escribir
cdigo 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 aadirlos al cuadro de herramientas. De
todos modos se recomienda utilizar el nuevo modelo declarativo de acceso a datos.
A continuacin veremos de manera muy prctica y directa la utilizacin de algunos estos objetos desde el
entorno. Al mismo tiempo que lo lee sera recomendable que realizase la prctica en su ordenador siguiendo
cada uno de los pasos indicados.
6.3.1.- Configurar un origen de datos
Abra Visual Web Developer 2005 y cree un nuevo sitio Web. Desde el cuadro de herramientas arrastre un
control SqlDataSource a la superficie del formulario que se ha abierto por defecto (que en el ejemplo hemos
renombrado como Datos.aspx). Obtendr un elemento rectangular como el de la figura que muestra un panel
de tareas que permite configurarlo:
Figura 6.1.- Panel de tareas de un control SqlDataSource.
Al pulsar sobre la tarea disponible se abre el asistente de configuracin del origen de datos. En el primer paso
del asistente se debe configurar la conexin con el origen de datos. Al pulsar el botn Nueva Conexin
aparece un dilogo que nos permite elegir el proveedor de datos que se desea utilizar:
Figura 6.2.- Elegir un origen de datos
2005 52
Desde aqu se puede elegir cualquier proveedor disponible en .NET, no slo para enlazarse con SQL Server
sino con cualquier otro tipo de base de datos. Elija el proveedor resaltado en la figura.
Nota:
Si se fija en la figura anterior ver que existen dos orgenes de datos para SQL Server. La diferencia entre ellos
estriba en que el primero permite la seleccin de un archivo fsico en disco y el segundo una base de datos
alojada en un servidor en funcionamiento. Como seguramente sabr SQL Server 2005 permite enlazar
dinmicamente archivos de bases de datos con un servidor cuando sea necesario acceder a ellas, cosa que
antes no era posible. De ah esta distincin.
Al aceptar se abre una nueva ventana que permite configurar el origen de datos elegido. En el caso concreto
de SQL Server la ventana de configuracin tiene el aspecto de la figura 6.3, y permite seleccionar el servidor a
usar, las credenciales de acceso a ste y la base de datos que se utilizar, aparte de poder probar la conexin.
Se parece mucho al dilogo de configuracin que ya conocemos de ADO clsico.
Figura 6.3.- Configuracin de origen SQL Server.
Elija la base de datos local (normalmente se llamar EQUIPO\SQLEXPRESS siendo EQUIPO el nombre de su
equipo), deje marcada la autenticacin de Windows y en la lista de bases de datos escoja Northwind o la base
de datos que desee utilizar.
Al aceptar se crea la nueva cadena de conexin y en el siguiente paso del asistente se nos pregunta si
deseamos almacenarla en el archivo de configuracin de la aplicacin, a lo que normalmente contestaremos
que s. Ello permite cambiar la conexin ms tarde slo con modificar el contenido de esta clave en el archivo
web.config, sin necesidad de tocar el cdigo.
En el paso siguiente hay que escoger qu consulta queremos utilizar para acceder a los datos.
2005 53
Figura 6.4.- Seleccin de consulta de recuperacin de datos.

Desde la interfaz mostrada podremos elegir directamente una tabla o una vista de nuestra base de datos como
consulta que recuperar los datos a mostrar, o bien incluso generar una consulta compleja mediante el uso de
un editor de consultas visual (primera opcin del dilogo).
Escoja la segunda opcin y seleccione la tabla Customers en la lista de tablas disponibles. Los botones de la
derecha nos permiten parametrizar un poco ms la consulta. El botn WHERE permite filtrar a mayores los
resultados a partir de valores constantes, parmetros, cookies o incluso valores de otros controles que
tuvisemos en la pgina. El botn ORDER BY sirve para elegir los criterios de ordenacin de resultados. El
botn Avanzadas merece que nos detengamos un poco ms.
Desde las opciones avanzadas se nos permite elegir si, adems de la consulta de recuperacin de datos,
tambin podemos crear automticamente las consultas de insercin, modificacin y borrado. stas son las
que utilizar un DataAdapter subyacente para realizar las actualizaciones de DataSet a la base de datos, tal y
como explicamos tericamente en el captulo anterior. Esto nos evita, tal y como afirmamos entonces, el
tener que escribirlas nosotros mismos y permite actualizar los datos directamente enlazndolos desde un
control, como veremos enseguida.
Adems de elegir si queremos comandos de actualizacin hay otra opcin que sirve para indicar si queremos
usar o no la concurrencia optimista.
La concurrencia optimista evita la actualizacin de registros en el caso de que haya variado cualquiera de sus
campos desde que se obtuvieron de la fuente de datos. Este comportamiento puede ser bueno en ciertas
ocasiones, cuando queremos preservar los cambios realizados por cualquier usuario. En otras sin embargo no
resulta de utilidad y s aade una gran sobrecarga al acceso a datos.
Se le denomina concurrencia optimista porque parte de la base de que la posibilidad de coincidencia de dos
usuarios sobre el mismo registro es baja y es un caso que apenas se dar. Al caso contrario a la concurrencia
optimista se le denomina concurrencia pesimista.
Nota:
En mi opinin debera 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 pequea en la mayora de los casos. Y de
todos modos el sobreescribir cierta informacin no suele ser un problema grave salvo cuando hablamos de
cuestiones de dinero, facturas y similares.
Cuando se establece la concurrencia optimista las consultas que genera el asistente de VWD incluyen todos
los campos del registro como condicin de bsqueda del mismo, por ejemplo:
DELETE FROM [Customers] WHERE [CustomerID] = @original_CustomerID AND
2005 54
[CompanyName] = @original_CompanyName AND [ContactName] = @original_ContactName

AND [ContactTitle] = @original_ContactTitle AND [Address] = @original_Address AND
[City] = @original_City AND [Region] = @original_Region AND [PostalCode] =
@original_PostalCode AND [Country] = @original_Country AND [Phone] =
@original_Phone AND [Fax] = @original_Fax
mientras que en un caso de concurrencia pesimista se emplea simplemente la clave primaria del registro para
localizarlo:
DELETE FROM [Customers] WHERE [CustomerID] = @original_CustomerID
Es decisin suya qu tipo de actualizacin 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.
Siguiendo con el asistente, si pulsamos el botn Siguiente se nos permite revisar los resultados devueltos
por la consulta de recuperacin de datos para hacer una ltima comprobacin y ver que son los que
necesitbamos. Al pulsar el botn Finalizar se termina el asistente y ya tenemos el origen configurado.
Si vamos a ver el origen y el cdigo VB de la pgina veremos que todos los ajustes se han especificado de
manera declarativa en el HTML sin haberse generado ni una sola lnea de cdigo nueva para configurar el
origen de datos. Esto contrasta poderosamente con el enlace a datos de otras versiones de ASP.NET ya que
en stas s se generaba gran cantidad de cdigo.
6.3.2.- Explotar el origen de datos
A continuacin vamos a utilizar el origen de datos para mostrar en la pgina Web los resultados de la consulta
que hemos definido antes y tambin habilitar su edicin y eliminacin, todo ello sin escribir cdigo alguno.
Arrastre un control GridView desde el cuadro de herramientas justo debajo del origen de datos que acabamos
de configurar. Su aspecto inicial con las tareas desplegadas ser el de la figura siguiente:
Figura 6.5.- Nuevo GridView y su panel de tareas.
Lo primero que haremos ser seleccionar el origen de datos a enlazar con la rejilla. En la lista desplegable de
su panel de tareas ya estar disponible el que hemos creado (podramos crear uno nuevo desde ella tambin),
as que eljalo.
Al hacerlo se generan de manera automtica en la rejilla las columnas necesarias para visualizar todos los
campos del resultado de la consulta del origen de datos (que es un DataSet). De este modo no tendremos que
elegirlas. Adems las tareas que se pueden realizar desde el panel de tareas de la rejilla han aumentado
sustancialmente, como se observa en la figura:
2005 55
Figura 6.6.- Rejilla enlazada al origen de datos.
Si habilitamos la paginacin se realiza de manera automtica el "trozeado" de los resultados de la consulta en

pginas y se habilita la navegacin por ellas. Al contrario que en versiones anteriores no es necesario escribir
cdigo o responder a eventos para conseguirlo.
Al habilitar la ordenacin las cabeceras de la rejilla se convierten en enlaces y, al ejecutar la pgina, cuando se
pulsa sobre ellas se ordenan los datos de la columna correspondiente, primero ascendentemente y luego a la
inversa. Todo ello tambin sin cdigo detrs asociado.
Podemos habilitar la edicin y la eliminacin de datos, lo que provocar que aparezcan sendos enlaces en una
columna adicional para hacerlo.
Las columnas que se visualizarn, el orden y tipo de stas as como otros ajustes relacionados (como por
ejemplo las caractersticas de la columna de comandos que acabamos de mencionar) se ajustan usando la
opcin Editar Columnas. Ello abre un dilogo como el de la siguiente figura con el que podremos
manipularlas a voluntad.
Figura 6.7.- Edicin de columnas de la rejilla.
2005 56
Otra tarea interesante desde el panel de la rejilla es la que dice Formato automtico. Al utilizarla se lanza un
dilogo desde el que podemos elegir entre diversos diseos predeterminados que mejoran mucho la
apariencia de la rejilla de datos.
Figura 6.8.- Formato automtico de la rejilla de datos.
Aparte del panel de tareas podemos usar la habitual ventana de propiedades del control para ajustar algunos
parmetros no disponibles desde el primero. Investigue un poco con l y ver algunos ajustes interesantes.
Este es el aspecto de nuestra rejilla en tiempo de diseo tras haber retocado su aspecto, las columnas que la
forman y algunos ajustes ms:
Figura 6.9.- Aspecto final de la rejilla.
Si ahora ejecutamos la aplicacin veremos una pgina HTML de navegacin de datos totalmente funcional y
para la que no se ha generado lnea de cdigo alguna.
2005 57
Figura 6.10.- Aspecto en ejecucin de nuestra rejilla.
Incluso podemos editar sus registros de manera sencilla pulsando el botn correspondiente que hemos
creado antes:
Figura 6.11.- Edicin de un registro.
Ntese como los campos se convierten en controles de servidor y los botones del registro que estamos
editando cambian automticamente a Actualizar y Cancelar para facilitar el trabajo de edicin.
Del mismo modo que en este ejemplo podemos usar otros controles, como por ejemplo el DetailsView para
mostrar informacin de manera ms flexible todava. Practique por su cuenta e investigue un poco ms estos
aspectos para dominar el trabajo de enlazado de datos en ASP.NET 2.0.
2005 58
CAPTULO 7
MASTER PAGES, TEMAS Y SKINS

ASP.NET 2.0 OFRECE UNA SERIE DE NUEVAS CARACTERSTICAS QUE NOS AYUDAN
A INDEPENDIZAR MS QUE NUNCA EL ASPECTO DE NUESTAS PGINAS DEL CODIGO
Y LOS CONTROLES QUE LAS CONFORMAN. EN ESTE CAPTULO APRENDEREMOS A
DEFINIR PLANTILLAS DE PGINAS Y TEMAS QUE LUEGO VARIARN EL ASPECTO DE
NUESTRAS APLICACIONES CON SLO REALIZAR UN AJUSTE.
Lo ms habitual cuando se crea una aplicacin o un sitio Web es que las pginas que lo conforman sean todas
bastante parecidas o al menos que existan varios grupos de pginas similares que slo varan ciertos
contenidos entre ellas. Por ejemplo, puede haber una categora de pginas para mostrar artculos en el que
todas son iguales excepto por el contenido del propio artculo en su parte central, mientras que en otra zona
de la aplicacin el diseo es completamente diferente pero sus pginas se parecen todas entre s.
Por ejemplo, la siguiente figura muestra capturas de dos pginas pertenecientes al portal MSDN:
Figura 7.1.- Ejemplo de dos pginas similares en MSDN
Ambas pginas difieren nicamente en el contenido y los mens que muestran en el lateral (los banners del
lateral son rotativos), y conservan una esttica y una serie de elementos que permanecen constantes en todas
las pginas del sitio.
Tradicionalmente para conseguir esta similitud entre pginas haba que crearlas individualmente o recurrir a
artificios propios como por ejemplo el de utilizar archivos de inclusin para renderizar ciertas partes de las
pginas desde un mismo origen en disco. An en este ltimo caso la capacidad de modificacin era limitada y
normalmente se reduca a las cabeceras y pies de las pginas y poco ms. En el primero de los casos (retocar
una a una) cualquier cambio esttico de un sitio medianamente grande era poco menos que una locura de
realizar.
ASP.NET 2.0 ofrece una nueva caracterstica destinada a paliar esta tradicional carencia y permite definir
pginas cuyo aspecto y funcionalidad deriva de unas pginas especiales comunes llamadas Pginas
principales o Master Pages.
Nota:
Aunque normalmente soy partidario de utilizar los trminos en castellano siempre que los haya, en este caso
har una excepcin y durante el resto del texto emplear el trmino anglosajn Master Pages (o MP) para
referirme a esta caracterstica. El motivo es que este trmino es el ms aceptado y el que veremos con ms
frecuencia y adems considero que la traduccin "Pginas principales" no ha sido la ms afortunada.
2005 59
7.1.- Qu son las Master Pages?
Una Master Page (MP) proporciona una forma de definir una estructura e interfaz comunes para un grupo de
pginas pertenecientes a un mismo sitio Web. Esta estructura comn se almacena en un nico archivo
independiente. Ello facilita mucho su mantenimiento puesto que, para actualizar todas las pginas que lo
utilizan, basta con editar dicho archivo.
Una MP es en realidad como una pgina ASPX normal que contiene cdigo, elementos HTML y controles
Web de servidor. Sin embargo posee una extensin diferente (.master) y utilizan una directiva <% @ master
%> en lugar de una directiva <% @ page %>. Por lo dems se pueden considerar prcticamente equivalentes.
Esto es importante porque significa que ya sabemos todo lo necesario para crearlas.
Una pgina ASPX normal puede derivar su estructura a partir de una MP simplemente aadiendo un atributo
MasterPageFile a su directiva de pgina, as:
que indica el archivo de pgina principal que se utilizar para su estructura.
7.1.1.- Definicin de una Master Page
Para agregar una Master Page a nuestro proyecto slo hay que elegir el icono Pgina Principal en el dilogo de
agregar nueva referencia de cualquier carpeta del mismo:
Figura 7.2.- Plantilla de Master Page.
Al abrir una MP aparece un diseador idntico al de una pgina ASPX normal. Podemos arrastrar sobre su
superficie cualquier control as como editar su HTML de la manera usual. Tambin lleva un archivo de cdigo
asociado en el que se puede responder a sus diversos eventos. La nica diferencia apreciable a simple vista
respecto a una pgina normal es que contiene por defecto un control de tipo ContentPlaceHolder. La
sintaxis de este control es anloga a la siguiente:
Su nica propiedad interesante es precisamente su identificador ya que este tipo de control se utiliza para
marcar las posiciones en las que irn los diferentes contenidos de las pginas derivadas dentro de la plantilla
de estructura que es una Master Page.
De este modo, cuando una pgina normal derive de una MP, slo se podr introducir cdigo dentro de las
zonas definidas por estos comodines de contenido.
2005 60
Cuando aadimos una nueva pgina ASPX a nuestro proyecto y existe al menos una Master Page, podemos
marcar una opcin para que, antes de crearla, nos permita seleccionar de qu MP derivar:
Figura 7.3.- Seleccin de una MP al crear una nueva pgina.
Esto nos evita tener que escribir el atributo MasterPageFile manualmente.
Al editar una pgina que deriva de una Master Page aparece el aspecto y estructura de la pgina principal en el
diseador, pero slo se pueden tocar las partes correspondientes a los comodines de contenido.
7.1.2.- Acceso a los elementos de una Master Page
Es posible acceder a los controles y elementos de una pgina principal desde el cdigo de una pgina derivada
a travs de una directiva especial llamada MasterType. Slo 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 pgina de la que deriva la actual a travs de su
propiedad Master.
Por ejemplo, si nuestra Master Page tiene un elemento de imagen llamado 'Logo' y queremos variarlo en cada
pgina mediante cdigo slo habra que escribir:
Master.FindControl("Logo")
Lo mejor, sin embargo, es definir propiedades en la Master Page que encapsulen el acceso a sus elementos. El
cdigo anterior devuelve un objeto de tipo Control que deberemos convertir en un control de imagen y
asignarle la ruta al logo a utilizar. Es ms mucho ms fcil, menos propenso a errores y de mejor
mantenimiento futuro el definir una propiedad Logo en nuestra Master Page y acceder a ella escribiendo, por
ejemplo:
Master.Logo = "http://www.microsoft.com/logo_msdn.gif"
que nos aislar de lo que ocurra debajo para gestionar ese logo.
2005 61
Cree una pgina principal en su equipo en un proyecto de prueba y juegue con ella asignndola a otras pginas
tal y como se ha indicado. As comprender mejor su funcionamiento.
7.2.- Temas y Skins
Gracias a las Master Pages podemos definir una estructura comn para las pginas de nuestra aplicacin Web.
Sin embargo an no hemos resuelto todas las cuestiones sobre el mantenimiento de la interfaz que habamos
planteado. Los controles que aadamos a las zonas de contenido de nuestras pginas todava tendrn el
aspecto predeterminado. Podemos configurar su aspecto estableciendo las propiedades de apariencia del
control (como BackColor, Font, etc...). El problema que tiene este mtodo es que, si deseamos cambiar por
completo la apariencia de estos controles, tendramos que tocar una por una todas las pginas. Esta no es una
opcin admisible en cuanto la aplicacin dispone de ms de unas pocas pginas.
Veamos las opciones que nos ofrece ASP.NET 2.0 para solventar esta otra parte de un mismo problema.
7.2.1.- Hojas de estilo
HTML ofrece una interesante opcin para independizar el aspecto de sus elementos del contenido de las
pginas a travs 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 pgina. Aunque se pueden definir
dentro de la propia pgina, hacerlo as les hace perder su verdadero sentido que no es otro que el de separar la
definicin del aspecto. As, es posible crear archivos con extensin '.css' que se vinculan a las diferentes
pginas de un sitio y definen el aspecto de sus elementos.
Dentro de una hoja CSS se definen fundamentalmente dos tipos de estilos:
Redefinicin de etiquetas: indican qu aspecto deben tener todas las etiquetas de un determinado
tipo en las pginas a las que est vinculado el archivo. Por ejemplo:
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 pgina.
Clases: definen aspectos que no estn 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;
}
.....
<a href="http://msdn.microsoft.com" class="EstiloSimple">MSDN</a>
2005 62
En este caso se define la clase llamada EstiloSimple, y cualquier etiqueta HTML a la que se le asigne
mediante su atributo class adquirir el aspecto marcado.
Para asignar un archivo CSS a una pgina slo hay que incluir en su cabecera una lnea anloga a esta:
<link href="mi_hoja.css" rel="StyleSheet" />
La gran ventaja de esta tcnica es que basta con tocar el archivo CSS para que todas las pginas que lo utilizan
vean su aspecto modificado de manera acorde a los cambios. Da igual que sea slo una o haya miles. Al tener
el aspecto centralizado en una ubicacin nica el mantenimiento es muy sencillo.
Lo anterior es una caracterstica de HTML independiente de lenguajes de programacin como ASP.NET. Por
supuesto ASP.NET tiene en cuenta y soporta perfectamente las hojas CSS. Se puede aadir una etiqueta
<LINK> a la cabecera de una pgina ASPX y los elementos HTML que se generan a partir de los controles
que contiene se mostrarn siguiendo las indicaciones de la misma.
El entorno de desarrollo de VWD permite definir los estilos de los controles HTML de servidor de
ASP.NET utilizando su propiedad Style, tanto en tiempo de diseo como durante la ejecucin. El diseador
de pginas ASPX incluso ofrece un dilogo especializado para crear los estilos.
En el caso de los controles Web de servidor se utilizan sus propiedades de aspecto (que se traducen en estilos
al renderizarse en un navegador moderno), y adems disponen de
una propiedad llamada CssClass para establecer mediante cdigo el
nombre de las clase que se quiere aplicar al control (se traduce en un
atributo Class normal de HTML en tiempo de ejecucin).
Tambin se puede aplicar un estilo concreto a ciertos controles

directamente desde el marcado de la pgina ASPX, como por
ejemplo:
<ASP:Calendar ... runat="server">

<TitleStyle BorderColor="blue" BorderWidth="1"
BackColor="olivedrab" Height="50px" />
</ASP:Calendar>
si bien en este caso no se usan atributos normales de CSS.
7.2.2.- Temas y mscaras (Skins)
Si bien las hojas de estilo resuelven en gran parte el problema de independizar el aspecto de la definicin de
contenidos de una pgina, no se adaptan por completo a los controles ASP.NET. Adems dejan fuera algunas
funcionalidades, como los valores por defecto de propiedades de controles (por ejemplo el texto inicial de un
campo) o el aspecto de controles Web complejos como calendarios o rejillas que no se pueden expresar
nicamente con un estilo CSS.
ASP.NET 2.0 introduce una interesante novedad que se complementa la perfeccin con las Master Pages
para solventar el problema del aspecto: los temas y mscaras de controles Web.
La funcionalidad ofrecida por los temas de ASP.NET 2.0 se entiende fcilmente 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 prcticamente idntica a la de los controles cuyo aspecto definen. Enseguida lo
entenderemos.
7.2.3.- La carpeta App_Themes
Un tema de ASP.NET 2.0 est formado por uno o varios archivos de tipo .skin junto con las imgenes y
hojas de estilo CSS que stos utilicen, que se almacenan dentro de una carpeta con el nombre del tema dentro
2005 63
de una carpeta especial. Esta carpeta de nombre especial es App_Themes. Podemos aadir una carpeta de
temas con el men de agregar carpeta de un proyecto de Visual Web Developer:
Figura 7.4.- Nueva carpeta especial App_Theme.
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 dilogo que aparece seleccionaremos un
archivo de mscara, como se muestra en la figura:
Figura 7.5.- Nuevo archivo de mscara (Skin)
El primer archivo de mscara que agreguemos definir

automticamente una carpeta de tema con su mismo nombre para
contenerlo.
Podemos definir manualmente tantas carpetas de tema como queramos

usando el men de agregar nuevas carpetas. Dentro de cada una de
esas carpetas puede haber tantos archivos de mscara, hojas de estilo y
grficos como necesitemos.
Por ejemplo el grfico del lateral muestra una carpeta App_Theme que
contiene dos temas y cada uno de ellos a su vez contiene un archivo
.skin, hojas CSS y grficos especficos del tema.
2005 64
7.2.4.- Estructura de un archivo .skin
Un archivo de mscara contiene definiciones de controles ASP.NET a los que se le establecen valores de
propiedades que sern aplicadas de modo automtico cuando aparezcan en una pgina que use el tema al que
pertenece la mscara. Por ejemplo, si un archivo .skin contiene el siguiente cdigo:
conseguiremos que las pginas que lo apliquen dispongan de controles TextBox con el fondo gris claro y el
borde punteado de 1 pxel de ancho. Las rejillas que se utilicen automticamente tendrn el fondo blanco y las
lneas pares azules.
Si nos fijamos, la nica diferencia entre un elemento del archivo de mscara y el marcado de un control est
en que los primeros carecen del atributo de identificacin ID. Por lo dems son prcticamente idnticos.
TRUCO:
Dado que VWD no proporciona asistencia para crear archivos de mscara (es un simple editor de texto), una
forma sencilla de definir sus elementos es utilizar una pgina ASPX vaca para arrastrar y configurar controles
con los aspectos deseados. Luego slo hay que copiar su definicin al archivo .skin eliminando todos los
atributos ID.
7.2.5.- Propiedades que se pueden personalizar
Aunque los archivos de mscara estn pensados para facilitar la aplicacin de propiedades estticas de los
controles, lo cierto es que se puede definir casi cualquier otra propiedad de un control. Por ejemplo, si
escribimos lo siguiente en el archivo .skin de un tema:
todos los controles de tipo TextBox de nuestra aplicacin mostrarn el texto "(valor)" al cargar las pgina que
usen este tema (ntese el atributo Text en la primera lnea).
En realidad cualquier propiedad de un control Web puede personalizarse mediante un archivo de mscara a
menos que su creador haya indicado explcitamente lo contrario. Esta particularidad puede resultar muy
interesante en ciertos casos.
Nota:
Los creadores de controles pueden emplear el atributo ThemeableAttribute para indicar que una
propiedad no es personalizable mediante una mscara.
Por supuesto en las propiedades de los elementos de una mscara se pueden utilizar imgenes como en este
ejemplo:
Debemos guardar las imgenes en alguna subcarpeta de la carpeta de recursos del tema y utilizar rutas
relativas a sta para los atributos que las utilicen, como en el ejemplo. ASP.NET se encarga de modificar las
rutas para que apunten al lugar correcto tras la aplicacin del tema.
7.2.6.- Asignacin de temas
2005 65
Ahora que ya conocemos la teora acerca de los temas y sabemos crear archivos de mscara para los temas
vamos a aprender a utilizarlos en la prctica.
Para que una pgina se adapte automticamente a un tema definido en la carpeta App_Themes lo nico que
tenemos que hacer es asignar un atributo Theme en la directiva de la pgina, as:
El segundo atributo indica el tema que se va a aplicar. El entorno de desarrollo de VWD nos ofrece de
manera automtica una lista de temas disponibles al escribir este atributo por lo que es muy fcil escribirlo.
Nada ms establecer el atributo la pgina se personaliza en tiempo de ejecucin siguiendo los dictados de los
archivos .skin que haya definidos para el tema. Dado que podemos disponer de varios temas se puede asignar
uno diferente a cada grupo de pginas de una aplicacin segn las necesidades.
Nota:
Lo ms interesante de este atributo Theme es que se puede establecer en cualquier momento. Es decir,
podemos desarrollar una aplicacin completa sin pensar siquiera en los temas, y aadrselos sin demasiado
esfuerzo al final con slo asignarlo. Ello permite adems separar la labor de diseo de la de desarrollo que
incluso la puede hacer un equipo de trabajo diferente.
7.2.7.- Asignacin global de temas
El uso del atributo Theme es muy adecuado cuando slo tenemos unas pocas pginas a las que aplicrselo. En
aplicaciones grandes el hecho de tener que recorrer las pginas una por una para asignarlo puede ser muy
tedioso, con lo que perderamos bastante de la productividad ganada.
Para evitar esta situacin ASP.NET ofrece otra forma de establecer los temas de forma global. Consiste en
aadir un nuevo nodo de tipo <pages theme=.../> al archivo de configuracin de la aplicacin, el archivo
web.config. La entrada sera similar a la siguiente:
Al hacerlo todas las pginas de la aplicacin utilizarn el tema indicado sin necesidad de establecerlo
manualmente.
Si se define un tema especfico para una pgina, ste tendr precedencia sobre el ajuste de Web.config. De
hecho si deseamos que una pgina no utilice tema alguno slo hay que establecer su atributo Theme a una
cadena vaca ("").
Nota:
Dado que una aplicacin Web puede disponer de varios archivos de configuracin (uno por cada carpeta) si
queremos que la aplicacin emplee un tema diferente en diferentes zonas slo tenemos que guardar todas las
pginas de cada zona en una carpeta diferente y crear archivos web.config especficos para indicar el tema en
cada una de ellas. Las carpetas que no dispongan de su propio web.config heredarn el tema principal del sitio.
7.2.8.- Clases de un mismo tipo de control
El hecho de declarar un elemento genrico dentro de un archivo de mscara es til pero no lo suficiente. Lo
ms normal es que no todas las etiquetas o botones (por poner un ejemplo) tengan exactamente el mismo
aspecto sino ms bien que existan varios tipos de etiquetas y botones que se empleen segn la ocasin.
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 especficos. La forma de distinguir unos de otros es a travs del atributo
SkinID. Considere el siguiente ejemplo:
2005 66
En este caso se han definido tres clases de controles TextBox. Los dos primeros tienen asignado un SkinID y
slo se aplicarn a aquellos controles TextBox cuya propiedad SkinID coincida con el SkinID de la definicin.
La ltima definicin 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 especficamente un SkinID.
Lo habitual es separar los distintos grupos de controles es varios archivos .skin dentro de la carpeta de un
tema. Se reconocern como si estuvieran todos en el mismo archivo pero es ms ordenado gestionarlos por
separado.
2005 67
CAPTULO 8
ESTADO DE LAS APLICACIONES

EN ESTE CAPTULO ESTUDIAREMOS LAS FORMAS MS IMPORTANTES QUE TIENE
ASP.NET DE MANTENER INFORMACIN ALBERGADA EN MEMORIA Y DE RESOLVER
LAS DIFICULTADES ASOCIADAS A QUE HTTP ES UN PROTOCOLO SIN ESTADO.
Existen diferentes mtodos para mantener el estado de una aplicacin y sus utilidades en la prctica son
muchas, entre otras:
Almacenar temporalmente datos costosos de obtener para mejorar el rendimiento.

Compartir informacin entre todas las pginas de una aplicacin, distinguindola por cada usuario o
de manera comn a todos.
Guardar detalles de un usuario entre diferentes visitas a una aplicacin.
Mejorar el rendimiento evitando que se rendericen por completo o en parte las pginas de nuestro
sitio Web.
8.1.- Mantenimiento de sesiones
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 algn
modo un estado que les permita agrupar de manera lgica las llamadas. Sin ello no habra forma, por ejemplo,
de distinguir dos llamadas a una misma pgina de dos usuarios diferentes. Para conseguir este artificio sobre
un protocolo sin estado ASP.NET proporciona las sesiones.
Nota:
Cabra pensar que una buena forma de distinguir unas llamadas de otras en una aplicacin Web es a travs de
la direccin IP del cliente. Nada ms lejos de la realidad. Dos usuarios diferentes que accedan detrs de un
mismo router (por ejemplo, dos personas en una misma oficina) tienen la misma IP exactamente. Adems,
desde el punto de vista de la seguridad es muy mala idea usar invariantes de este estilo pues son fciles de
falsear.
8.1.1.- Variables de sesin
ASP.NET ofrece una coleccin llamada Session en el objeto Page que nos permite almacenar parejas de
claves y valores que estn disponibles desde todas las pginas de una aplicacin y se distinguen
automticamente para cada cliente que las utilice.
Esto implica que podremos almacenar valores de cualquier tipo a los que podremos cuando sea necesario
mientras el usuario que solicite las pginas sea el mismo. Por convencin a las parejas de claves y valores
almacenados en el objeto Session se les denomina variables de sesin.
Por ejemplo, si quiero contar cuantas veces ha pasado un usuario por una pgina 'a.aspx' puedo escribir en su
evento Load lo siguiente:
Session("Cuenta") += 1;
Esto hara que el valor asociado con la clave Cuenta se incrementara en uno cada vez que se cargue la pgina.
Es decir, en palabras llanas, incrementa en la unidad el valor de la variable de sesin Cuenta.
Si creamos una segunda pgina 'b.aspx' en la que mostramos el valor de la variables de sesin mediante:
Response.Write(Session("Cuenta"))
2005 68
veremos que la variable se incrementa en cada ocasin como esperbamos, a pesar de que, en principio, cada
peticin HTTP es independiente de las dems. Si abrimos un nuevo navegador veremos que las pginas en
ste generan una cuenta independiente.
8.1.2.- Funcionamiento bsico de las sesiones
Si cada llamada HTTP es independiente de las dems, cmo es posible el comportamiento anterior?. Por
defecto ASP.NET mantiene la ilusin de las sesiones mediante el uso de cookies de sesin. Este es un
sistema anlogo (aunque diferente) al que ya ofreca ASP 3.0 clsico para el mismo propsito.
Una cookie de sesin no es ms que una cabecera HTTP con un identificador nico que el servidor enva al
cliente en la primera peticin que ste hace y que el navegador se encarga de reenviar automticamente en las
sucesivas peticiones. As, basta con comprobar esta cabecera en el servidor en cada peticin para averiguar
qu usuario es el que la realiza. As de simple.
Este es el aspecto de una cookie de sesin de ASP.NET:
ASP.NET_SessionId=43s3ir55u0vvlj55smesaj45
Este fragmento es el que se enva en la cabecera de las peticiones, siendo el valor despus del igual el
identificador nico utilizado para esa sesin. Estas cookies de sesin no se almacenan jams a disco y slo
existen mientras el navegador est abierto. Si cerramos el navegador no podremos recuperar la anterior
sesin.
8.1.3.- Sesiones sin cookies
El sistema de cookies de sesin 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 sesin en su
navegador todo dejar de funcionar.
Para evitar este problema ASP.NET dispone de un mtodo alternativo para mantenimiento de sesin que no
utiliza cookies ni cabeceras, sino que introduce una ruta virtual aleatoria en todas las peticiones de modo que
todas son distintas. Si la llamada a una pgina se efectuaba en esta URL:
http://www.miservidor.com/miapp/pagina.aspx
al habilitar las sesin sin cookies la llamada se convierte en algo similar a:
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 pginas de ASP.NET es capaz de distinguir que se trata de un identificador de sesin y actuar de manera
transparente para mantenerla y enviar las peticiones a las pginas correctas.
Este mtodo es menos propenso a fallos que el anterior pero tiene el inconveniente de que se generan URLs
mucho ms largas y menos atractivas. Las sesiones sin cookies no existan en ASP 3.0.
Habilitar este tipo de sesiones es muy sencillo. Basta con abrir el archivo de configuracin de la aplicacin
(web.config) y aadir el siguiente ajuste dentro del nodo <system.web>:
<sessionState cookieless="UseUri" />
8.1.4.- Duracin de las sesiones
2005 69
Una sesin se mantiene en memoria en el servidor mientras no transcurra ms de un determinado tiempo sin
recibir actividad por parte de un usuario. Por defecto Internet Information Server mantiene vivas las sesiones
durante 20 minutos, pero se puede cambiar este ajuste desde las propiedades avanzadas de cualquier servidor
o directorio virtual.
Figura 8.2.- Establecimiento del tiempo de sesin en IIS
Tambin se puede establecer desde la configuracin de la aplicacin (web.config) usando el atributo timeOut
del mismo nodo que hemos estado usando hasta ahora:
<sessionState timeout="10"/>
Del mismo modo se puede asignar mediante cdigo usando la propiedad Timeout del objeto Session.
Session.Timeout = 10
Si transcurre el nmero de minutos marcados sin recibir nuevas peticiones de un mismo usuario los datos de
la sesin se eliminan automticamente. Hay que tener cuidado con esto porque nunca sabemos cuando puede
ocurrir, por lo que jams debemos dar por hecho que una determinada variable de sesin existe.
Podemos forzar el abandono de una sesin desde el cdigo llamado al mtodo Abandon del objeto Session:
Session.Abandon()
8.2.- Informacin comn
8.2.1.- Almacenamiento en cach
ASP.NET ofrece un potente sistema de almacenamiento en cach que guarda los objetos en memoria y es
privado para cada aplicacin. De forma anloga a las variables de sesin, existe un objeto Cache que
proporciona una interfaz indexada que permite establecer y recuperar pares de clave-valor. As podemos
escribir:
Cache("MiClave") = miValor
2005 70
....
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.
Con la cach de ASP.NET es muy fcil conseguir la caducidad automtica de sus elementos.
Por ejemplo, imaginemos que leemos en la variable de cach 'datos' el contenido de un archivo XML y
queremos guardarlo en memoria para uso comn y evitar as el continuo acceso a disco para leer el contenido.
Para conseguir que esta cach se invalide y desaparezca de forma automtica cuando cambie el contenido del
archivo basta con escribir la siguiente lnea:
Cache.Insert("MisDatos", datos,
New CacheDependency(Server.MapPath("misdatos.xml")))
En lugar de usar la interfaz de indexacin directa de elementos del objeto Cache usamos su mtodo Insert
que en una de sus versiones sobrecargadas permite agregar una dependencia a un archivo. A partir de ese
momento si el archivo 'misdatos.xml' cambia, el elemento desaparece de la cach y lo volveremos a cargar
la prxima vez que se consulte.
Tambin se puede establecer la fecha de caducidad de un elemento de la cach con otra versin sobrecargada
del mtodo Insert:
Cache.Insert("MisDatos", datos, Nothing, DateTime.Now.AddHours(2), TimeSpan.Zero)
Esta lnea agrega el elemento sin dependencia en objeto alguno y con una fecha de caducidad para dentro de
dos horas.
Cache.Insert("MisDatos", datos, Nothing, DateTime.MaxValue, TimeSpan.FromMinutes(30))
En este caso la caducidad es relativa e indica que el valor caducar en cuanto nadie haga uso de el durante 30
minutos.
Se pueden agregar dependencias a archivos en disco y a claves en el registro y tambin combinaciones de

estas dependencias. La clase CacheDependency se puede heredar para crear nuestros propios criterios de
caducidad de cach. Incluso es posible especificar un delegado a una funcin a la que queremos llamar
automticamente cuando el elemento expire y as recargarlo de inmediato.
Si estamos trabajando con SQL Server 2005 podemos aprovechar la existencia de su sistema de encolado de
mensajes (Message Broker) para crear dependencias de cach en consultas, de forma que cuando se modifiquen
los datos de una base de datos se reciba una notificacin automtica. Este mecanismo es muy potente y
conviene aprender a usarlo bien.
8.3.- Cach de salida
La cach de salida de ASP.NET es un mecanismo que nos permite decidir qu partes de una pgina deben
generarse en cada solicitud y cules pueden ser aprovechadas para posteriores peticiones. Su uso es
extremadamente sencillo y pueden aumentar de forma espectacular el rendimiento de cualquier aplicacin.
Si se define una directiva de cach para una pgina o un control de usuario, ASP.NET tras la primera peticin
no tiene que generarlos ni crear instancias de objetos, etc..., por lo que se obtiene un rendimiento muy
elevado ya que slo debe leer el resultado de memoria y devolverlo.
2005 71
Como se pueden aplicar las directivas de cach de salida a los controles de usuario, si necesitamos hace cach
slo de determinadas partes de una pgina y no de la pgina entera, podemos convertir stas en controles de
usuario y conseguir el efecto buscado.
8.3.1.- Directiva OutputCache
Para poder hacer cach del contenido de una pgina 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 algn parmetro, de una cabecera, etc...
Por ejemplo, la siguiente directiva:
indica que el contenido completo de la pgina o control deber mantenerse en cach durante 60 segundos y
que la pgina no vara en funcin de parmetro GET o POST alguno que se le pase. Todas las peticiones a
esta pgina recibidas mientras est en cach se obtienen directamente de ah, sin procesar la pgina. Tras pasar
los 60 segundos la pgina se elimina de la cach y la siguiente peticin se procesa de modo normal volviendo
a guardar el resultado en la cach durante otros 60 segundos.
En pginas que, por ejemplo, visualizan muchos resultados obtenidos de una base de datos y que varan con
poca frecuencia puede aumentar muchsimo el rendimiento.
8.3.2.- Atributos de OutputCache
Lo ms normal en muchas pginas es que el contenido vare en funcin de diferentes caractersticas, no que
permanezca invariable sin ms durante un determinado tiempo. Para amoldarse a diferentes situaciones la
directiva OutputCache dispone de varios atributos que permiten elegir el criterio de cach de los contenidos y
que son los siguientes:
VaryByParam: permite especificar que se haga una cach por cada valor diferente que tome un
parmetro que se le pasa a la pgina y que se indica en este atributo. Por ejemplo, si tenemos una
pgina a la que se le pasa un parmetro "pais" y que devuelve un listado de clientes en dicho pas, al
indicar VarByparam="Pais" conseguiremos una cach de resultados diferente para cada valor del
parmetro. Cuando se le pasa un nuevo valor se ejecuta la pgina y se almacena el resultado para las
restantes veces que se solicite con el mismo parmetro (durante el tiempo especificado). Si hay ms
de un parmetro se pueden especificar separndolos 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 versin en cach de la pgina por cada tipo
de navegador utilizado para acceder a la pgina. Se pueden especificar varias cabeceras separndolas
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 vlido en directivas de pgina, slo 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
funcin global GetVaryByCustomString (dentro de Global.asax) a la cual se le pasa el valor del
atributo para que pueda decidir cmo actuar. No vamos a entrar en ms detalles en este curso.
8.3.3.- Sustitucin post-cach
Esta es otra caracterstica de ASP.NET 2.0 que no estaba disponible en versiones anteriores de la plataforma
.NET.
2005 72
En ASP.NET 1.x si hacamos cach de una pgina en la que todo permaneca invariable excepto una pequea
regin que mostraba, por ejemplo, la hora, estbamos obligados a dividir la pgina en controles de usuario
para evitar la cach de esa pequea parte. ASP.NET 2.0 aade un nuevo tipo de control llamado
Substitution que permite hacer excepciones a la hora de almacenar en cach una zona de una pgina. Este
control est ubicado normalmente en la ltima posicin de la lista de controles estndar en el cuadro de
herramientas.
El control dispone de una propiedad MethodName que permite especificar el nombre de un mtodo
compartido (esttico) que devuelve una cadena con el texto o HTML a mostrar en su lugar cuando se genere
la pgina a partir de la cach. Este mtodo toma como parmetro un objeto HttpContext que nos permite
acceder al contexto de la llamada.
Por ejemplo, definimos la siguiente funcin:
y aadimos un control Substitution como este:
Si hacemos cach de la pgina se mantendr todo el contenido excepto el de este control que mostrar en
cada caso el valor devuelto por la funcin compartida DameLahora.
2005 73
CAPTULO 9
SEGURIDAD DE APLICACIONES
PRCTICAMENTE CUALQUIER APLICACIN QUE CREEMOS VA A NECESITAR
SEGURIDAD EN EL ACCESO A SUS DIVERSAS SECCIONES. LO HABITUAL ES TENER
APARTADOS A LOS QUE SLO PUEDEN ACCEDER MIEMBROS REGISTRADOS O UNA
ZONA DE ADMINISTRACIN RESTRINGIDA A LOS GESTORES DEL SISTEMA. ASP.NET
2.0 OFRECE MULTITUD DE NOVEDADES EN ESTE ASPECTO QUE NOS VAN A
SIMPLIFICAR MUCHO EL TRABAJO.
ESTE CAPTULO HABLA SOBRE LA SEGURIDAD DE APLICACIONES DESDE EL PUNTO
DE VISTA DE LA AUTENTICACIN Y LA AUTORIZACIN DE USUARIOS.
APRENDEREMOS LOS FUNDAMENTOS DE GESTIN DE ACCESO USANDO LAS
NUEVAS CARACTERSTICAS DE ASP.NET 2.0.
9.1.- Autenticacin de usuarios
Disponemos de diversas barreras a la hora de controlar el acceso a los recursos en nuestras aplicaciones Web.
La primera de ellas la constituye el propio servidor de aplicaciones que en entornos de produccin es
normalmente Internet Information Server (IIS).
9.1.1.- Autenticacin IIS/Windows
IIS permite definir mediante su configuracin tanto el modo en el que se autentica a los usuarios como los
permisos de acceso genricos que se ofrecen a los recursos que sirve. La siguiente figura muestra el aspecto de
la ventana que permite ajustar los mtodos de autenticacin que solicitar IIS a los usuarios:
Figura 9.1.- Configuracin de seguridad de IIS
2005 74
La ventana de la figura permite configurar si se admiten o no usuarios annimos, y en este ltimo caso cmo
se autenticarn stos contra el sistema. Se puede restringir tambin el acceso a un recurso (carpeta, directorio
virtual o archivo) en funcin de direcciones IP y dominios.
No vamos a profundizar en este aspecto pues se sale del mbito del libro, pero baste decir que, para sitios
Web grandes accesibles desde Internet la autenticacin de IIS (que se basa en usuarios de Windows) no es la
ms habitual porque se necesitara una licencia de acceso por 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.
9.1.2.- Autenticacin Forms de ASP.NET
Desde la primera versin de ASP.NET existe un mtodo de autenticacin conocido genricamente como
"Forms" que permite a los programadores crear un sistema propio de autenticacin de usuarios. En lugar de
utilizar usuarios del sistema (IIS debe permitir el acceso annimo a los recursos), en este caso es el
programador el que debe establecer su propio mecanismo de autenticacin, por ejemplo lanzando consultas
contra una base de datos.
El funcionamiento es el siguiente:
Figura 9.2.- Lgica de autenticacin personalizada en ASP.NET
Cuando un usuario solicita una pgina protegida ASP.NET comprueba si ste se encuentra ya autenticado o
no. Lo sabe porque cuando un usuario se ha autenticado previamente esta informacin se almacena en una
cookie cifrada. Si est autenticado se le permite el acceso al recurso siendo responsabilidad del programador
definir cualquier comprobacin de autorizacin posterior. En caso de no estar autenticado se le dirige de
forma automtica a una pgina que le solicita las credenciales de acceso.
Nota:
El uso de cookies era obligatorio en ASP.NET 1.x para utilizar la autenticacin Forms. ASP.NET 2.0 soporta la
autenticacin sin cookies de un modo muy similar al que hemos visto para sesiones sin cookies: introduciendo
una ruta virtual codificada en todas las peticiones. Slo hay que utilizar el ajuste <forms
cookieless="UseUri"> en el archivo de configuracin.
Activar la autenticacin Forms en una aplicacin es muy sencillo, y de hecho suele estar activada por defecto
cuando programamos con Visual Web Developer 2005. Basta con editar el archivo web.config y aadir la
siguiente lnea en la configuracin de <system.web>:
<authentication mode="Forms"/>
2005 75
Por defecto la pgina a la que se redirige a los usuarios annimos 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>
A partir de ahora todos los usuarios annimos se redirigirn a entrada.aspx para solicitarle las credenciales
de acceso. Una vez en esta pgina se debe solicitar al usuario unas credenciales y comprobarlas en una base de
datos o cualquier otro medio de almacenamiento. En ASPNET 1.x haba que crear toda la lgica desde cero y
apoyarse en la API de la autenticacin Forms para hacerlo. Como comprobaremos enseguida en ASP.NET 2.0
todo esto nos lo ahorraremos.
9.2.- Autorizacin de usuarios
Una vez que un usuario est autenticado, el proceso que regula a qu recursos tendr acceso se denomina
autorizacin.
Para realizar el control de acceso no slo llega con indicar qu mtodo de autenticacin se usar (en este caso
Forms). Adems hay que especificar a qu recursos se debe controlar el acceso y de qu manera. En ASP.NET
existen diversos modos de definir la autorizacin de acceso.
9.2.1.- Autorizacin de URLs
Consiste en la autorizacin de acceso a determinados recursos de la aplicacin Web (pginas ASPX, carpetas,
archivos...) refrindose a ellos a travs de su ruta relativa en el archivo de configuracin de la aplicacin.
Se especifica el nivel de acceso requerido mediante una o varias entradas en el nodo raz de web.config
(nodo <configuration>) que tienen un aspecto anlogo al siguiente:
<location path=facturas.aspx>
<system.web>
<authorization>
<allow users=jose, hector, pablo>
<allow roles=clientes, administradores>
<deny users="?"/>
</authorization>
</system.web>
</location>
Como se puede observar, la sintaxis es muy sencilla y bastante evidente:
- El nodo location especifica la ruta relativa al directorio actual cuyo acceso se desea controlar.
- Los nodos allow y deny se emplean para permitir o denegar el acceso a determinados usuarios o roles de
usuario. Se pueden especificar nombres concretos para stos o utilizar comodines especiales, como en el caso
del nodo deny del ejemplo:
? : representa a los usuarios annimos. En el ejemplo anterior se deniega el acceso a todos los
usuarios que no se hayan autenticado previamente.
* : indica que el criterio se aplica a todos los usuarios, tanto annimos como autenticados,
independientemente de su perfil de usuario. Por ejemplo, para permitir el acceso a todos los usuarios
autenticados ( o sea, a todos excepto a los annimos) se escribira:
<location path=facturas.aspx>
<system.web>
<authorization>
<allow users=*>
<deny users="?"/>
2005 76
</authorization>
</system.web>
</location>
Pueden incluirse tantos nodos location como sea necesario dentro del archivo de configuracin.
Lo habitual es incluir junto con el nodo de autenticacin un nodo de autorizacin explcito que deniegue el
acceso a todos los recursos a los usuarios annimos, as:
<authentication mode="Forms"/>
<authorization>
<deny users="?"/>
</authorization>
Dado que puede existir un archivo web.config por cada carpeta de la aplicacin se pueden establecer
distintos criterios de acceso a cada una, agrupando en ellas los archivos con el mismo nivel de acceso.
9.2.2.- Autorizacin imperativa
Este tipo de autorizacin es la que nos permite entremezclar explcitamente en nuestro cdigo
comprobaciones acerca de la identidad de los usuarios, tomando decisiones en funcin de stas. Ofrece un
control todava ms granular, ya que puede estar en cualquier lugar del cdigo, dentro de un miembro de una
clase.
Se fundamenta en el uso de la propiedad User de la clase Page. Esta propiedad devuelve una referencia a un
objeto homnimo, es decir, de tipo User. Su mtodo IsInRole permite averiguar la pertenencia del usuario
actual a un determinado perfil o rol y tomar decisiones en funcin del resultado.
Por ejemplo en la clase CuentaBancaria del ejemplo anterior permitira limitar el importe de una
transferencia en funcin del tipo de usuario que la realice, as:
Public Sub Transferencia(cantidad As Decimal)

If cantidad > 1000 Then
If User.IsInRole(interventor) Then
'Transferir
End if
End If
End Sub
En este fragmento vemos como se usa el mencionado mtodo para comprobar si el usuario es un interventor
antes de permitir cualquier transferencia de ms de 1.000 euros.
La principal ventaja de esta forma de autorizacin 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 cdigo convirtindolo
enseguida en muy difcil de mantener.
9.3.- La nuevas API: Membership y Roles
Todo lo mencionado hasta ahora es muy interesante pero todava carece de lo ms importante: cmo
autenticamos a los usuarios? Cmo sabemos a qu roles pertenecen?.
Hasta ahora estas preguntas las deba contestar el propio programador ya que en ASP.NET 1.x era su
responsabilidad definir los mtodos de autenticacin de sus aplicaciones. Ello implicaba normalmente escribir
cdigo de consulta contra bases de datos, el cual validara las credenciales de los usuarios y obtendra los
roles de los mismos. Luego se creaban objetos de seguridad (Principal e Identity) asignndole estos
valores y asocindolos al contexto de la aplicacin.
ASP.NET 2.0 nos libera por fin de todo ello y ofrece de serie una completa API de gestin de usuarios que
nos evita tener que reinventar la rueda en cada aplicacin.
2005 77
9.3.1.- Membership
Se trata de una nueva API que proporciona una sencilla interfaz de programacin para almacenar y recuperar
informacin sobre los usuarios de nuestras aplicaciones. Lo ms interesante de todo es que, al igual muchas
otras caractersticas nuevas de ASP.NET 2.0, est basado en un patrn de diseo de proveedores, lo que
permite cambiar los mtodos de trabajo y almacenamiento sin tocar el cdigo de la aplicacin. La figura 9.3
ilustra mejor este concepto.
Por defecto esta API utiliza SQL Server 2005 para almacenar toda la informacin de seguridad de una
aplicacin. Pero dada su arquitectura basada en proveedores podemos cambiar el modo de gestin con slo
un ajuste en el archivo de configuracin. Incluso es posible definir mtodos de gestin de usuarios propios
sin modificar el cdigo de nuestras aplicaciones. Esto nos permite reutilizar infraestructuras de seguridad
preexistentes que hubisemos creado para ASP.NET 1.x sin perder el trabajo.
Membership consta de una clase con este nombre que contiene ciertos mtodos estticos (compartidos) para
poder crear, eliminar y validar usuarios entre otras cosas. As, por ejemplo, para crear un usuario
escribiramos:
Membership.CreateUser("usuario", "clave")
y para validarlo slo hay que usar su mtodo ValidateUser:
Membership.ValidateUser("usuario", "clave")
que devuelve verdadero o falso en funcin de si las credenciales son o no vlidas.
Existe tambin una clase MembershipUser que representa las propiedades de los usuarios de la aplicacin.
9.3.2.- Roles
Esta API complementa a la anterior para permitir la gestin de los roles de un usuario y, al igual que sta, est
basada en el mismo patrn 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 mtodos de la
clase Roles son todos estticos 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")
que devuelve una matriz de cadenas de texto. Si dejamos el parmetro usuario en blanco nos devuelve los
roles del usuario actualmente autenticado.
9.3.3.- Administracin de seguridad de sitios Web
Con todo lo visto hasta ahora crear la seguridad de un sitio Web es muy sencillo. Slo hay que establecer la
autenticacin Forms de ASP.NET y utilizar Membership y Roles para gestionar a los usuarios.
An as todava queda trabajo. Hay que crear formularios de autenticacin y, antes de nada, hay que gestionar
los usuarios y los roles de la aplicacin.
2005 78
Aunque sera muy sencillo crear una aplicacin para hacerlo, ASP.NET 2.0 tampoco nos va a dejar solos con
esto. Ofrece una completa herramienta de administracin ya creada de serie y, como veremos enseguida, ni
siquiera nos obliga a crear interfaces comunes de autenticacin y gestin de sesiones.
Antes de nada hay que administrar usuarios y roles. Para ello slo tenemos que pulsar sobre el men Sitio
webConfiguracin de ASP.NET y se abrir una web que nos permite configurar la seguridad de la aplicacin.
Figura 9.3.- Sitio de configuracin de la seguridad de ASP.NET 2.0
Con esta herramienta podemos dar de alta, modificar o borrar usuarios y roles, adems de realizar algunos
otros ajustes. Al utilizarla se encarga de modificar el archivo web.config de nuestra aplicacin si es necesario
realizar algn ajuste.
Adems crea un archivo de base de datos llamado ASPNETDB.mdf en la

carpeta App_data.
Este archivo es una base de datos de SQL Server 2005 que se usa para
almacenar toda la informacin de seguridad de los usuarios. Se hace uso de
la nueva caracterstica de enlazado dinmico de bases de datos de SQL
Server para poder distribuir esta base de datos con la aplicacin y enlazarla
al motor de base de datos slo cuando se vaya a utilizar.
Puede utilizar el gestor de configuracin de seguridad accediendo a l desde

el men Sitio Web Configuracin de ASP.NET:
2005 79
Figura 9.4.- Acceso a la configuracin del sitio Web
El administrador de sitios Web utiliza las clases MemberShip y Roles para realizar su trabajo. Disponemos de su
cdigo fuente completo en la carpeta
C:\WINDOWS\Microsoft.NET\Framework\v2.0.xxxxx\ASP.NETWebAdminFiles\ y es interesante
examinarlo.
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
enigmtico mensaje "Introduzca otra contrasea" a menos que use claves de al menos 7 caracteres
de longitud e incluya en ellas un espacio o un carcter no alfanumrico como un asterisco o un guin bajo.
Este ajuste se puede cambiar mediante configuracin.
9.4.- Los controles Web de seguridad
Como hemos podido comprobar en los epgrafes anteriores, la

gestin de la seguridad de nuestras aplicaciones se ha simplificado
muchsimo con ASP.NET 2.0. Gracias a los objetos Membership y
Roles crear una interfaz de administracin de usuarios y control de
acceso es casi trivial. Podra ser ms fcil?
Pues lo cierto es que s.
ASP.NET 2.0 nos facilita todava ms el trabajo relacionado con la

seguridad gracias a la inclusin de los nuevos controles Web de
seguridad. Los podemos encontrar en el grupo Inicio de sesin del
cuadro de herramientas de Visual Web Developer (vea la figura
adjunta).
Estos controles nos dan ya hechas multitud de operaciones comunes de seguridad relacionadas con la interfaz
de usuario. Por ejemplo, el control Login permite disponer de un completo dilogo de autenticacin con slo
arrastrarlo sobre un formulario Web. El CreateUserWizard es un asistente con varios pasos que permite la
creacin automtica de nuevos usuarios. Todos ellos permiten la personalizacin, tanto parcial por medio de
propiedades, como absoluta usando plantillas. En el caso de los asistentes tenemos libertad de aadir nuevos
pasos o modificar los predeterminados a voluntad.
9.4.1.- El control Login
2005 80
Este control permite definir un completo dilogo de autenticacin en cualquier pgina, que adems soporta el
uso de temas.
Figura 9.5.- Control de inicio de sesin personalizado estticamente.
Adems de los elementos obvios permite configurar enlaces para acceder a la creacin de nuevos usuarios,
muestra mensajes de fallo de autenticacin, redirige automticamente a otras pginas al autenticar si es
necesario, etc... Todo ello se controla con facilidad desde la ventana Propiedades de VWD. Investigue un poco
sus propiedades desde el entorno y ver lo fcil que es usarlo.
Para validar a los usuarios internamente utiliza el mtodo ValidateUser de la clase Membership.
Por defecto, si ya hay un usuario autenticado, este control se oculta automticamente salvo cuando se ubica
en la pgina principal. Este comportamiento se cambia con la propiedad AutoHide en caso de necesitarlo. As
se permite cambiar la sesin de usuario.
9.4.2.- El control LoginStatus
Se utiliza para mostrar el estado actual de conexin de un usuario y permitir su desconexin. Cuando hay un
usuario autenticado el control muestra por defecto un enlace que permite desconectarse. Lo que ello provoca
es que se elimine la referencia al usuario actual en la propiedad User de la clase Page y que se reenve a la
pgina de autenticacin especificada en web.config para una iniciar nueva sesin.
Cuando no hay usuario alguno autenticado en el sistema el enlace apunta automticamente a la pgina de
autenticacin definida.
Se puede personalizar por completo para mostrar cualquier otra cosa en la superficie del control.
9.4.3.- El control LoginName
Muestra el nombre del usuario actualmente autenticado.
9.4.4.- El control LoginView
Se trata de un completo control que permite definir el contenido de una zona de la pgina en funcin de si el
usuario est o no autenticado, y en caso de estarlo incluso en funcin del rol o roles a los que est asociado.
Es interesante observar su panel de tareas:
Figura 9.6.- Control LoginView y su correspondiente panel de tareas.
2005 81
La primera de las acciones, Editar RoleGroups, permite definir los casos que existirn en funcin de los
roles. Por ejemplo si queremos mostrar un mensaje diferente segn sea un usuario annimo, un usuario
autenticado en general y un usuario que pertenece al rol de administradores, tendramos que aadir desde
Editar RoleGroups un RoleGroup con el texto "Administradores" ya que los otros dos casos siempre estn
definidos por defecto.
La lista Vistas contiene un elemento por cada RoleGroup adems de los correspondientes usuarios annimos
y autenticados en general. Al elegir un elemento cualquiera de esta lista cambia la plantilla mostrada en el
diseador. En la plantilla podemos introducir controles y cualquier otro elemento, y eso ser lo que ver el
usuario indicado por el RoleGroup correspondiente.
Gracias al control RoleView es extremadamente sencillo personalizar las vistas para cada usuario disendolo
visualmente.
9.4.5.- Los controles restantes
PasswordRecovery, ChangePassword y CreateUserWizard nos facilitan la recuperacin de claves, el

cambio de clave y la creacin de usuarios respectivamente.
Al igual que los anteriores ofrecen una altsima capacidad de personalizacin que en el caso del control de
creacin de usuarios permite incluso aadir 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 configuracin
de la aplicacin. As pues, por ejemplo, el control de cambio de contrasea o el de creacin de usuarios
exigirn a las contraseas la complejidad indicada en la configuracin, y el de recuperacin de clave le har
una pregunta de seguridad si as est definido.
Gracias a estos controles y a la utilidad de administracin de seguridad de ASP.NET podemos construir la

seguridad completa de una aplicacin Web en cuestin de minutos, cuando lo habitual sera que tardsemos
horas o das.
2005 82
CAPTULO 10
INTRODUCCIN A LOS
SERVICIOS WEB CON ASP.NET
Este mdulo presenta al alumno los fundamentos de los Servicios Web y las
Arquitecturas Orientadas a Servicios (SOA). Tras una introduccin 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 Web Developer 2005 Express.
10.1.- Qu son los Servicios Web?
La expresin "Servicio Web" se oye con fuerza desde hace unos aos en el mbito del desarrollo de
aplicaciones e incluso en ambientes poco tcnicos y de direccin. Lo cierto es que no se trata de un concepto
tan novedoso como cabra esperar y las innovaciones que conlleva no son tanto tecnolgicas, como
conceptuales.
En este epgrafe explicaremos desde un punto de vista no-tcnico los conceptos relacionados con los
Servicios Web, cmo funcionan, de dnde vienen y a dnde van.
10.1.1.- Un poco de historia: modelos de desarrollo
El hecho de poder comunicar componentes de software entre s tiene una enorme importancia. Hasta no
hace tantos aos era muy tpico hacer aplicaciones de una sola pieza, "monolticas":
Figura 10.1.- Aplicacin "monoltica" aunque distribuida.
Estos programas podan acceder a un sistema gestor de datos a travs de la red, pero toda la lgica 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 tambin como "fat clients".
La situacin 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).
Una metodologa de desarrollo mucho mejor aunque ms laboriosa a la hora de programar es el modelo
Cliente-Servidor en tres capas:
2005 83
Figura 10.2.- Aplicacin Cliente Servidor en tres capas.
En este modelo toda la lgica de los datos, su validacin, los permisos, etc, residen en un servidor intermedio
y son utilizados por todos los clientes a travs de una red. En este caso en el ordenador del usuario lo nico
que hay es una capa de presentacin que se ocupa bsicamente de recoger y recibir datos, es decir, acta de
intermediario entre el usuario y las reglas de negocio residentes en la capa intermedia. Este modelo es ms
eficiente y est muy evolucionado respecto al anterior pero an se puede ir ms all.
La arquitectura de desarrollo en n-capas (n-tier que dicen los anglosajones) lleva el concepto cliente-servidor
un paso hacia adelante, dividiendo la capa intermedia en muchas otras capas especializadas cada una de las
cuales puede residir en un servidor diferente:
Figura 10.3.- Arquitectura de desarrollo basada en componentes.
En este modelo existe una gran variedad de componentes especializados en tareas especficas como la
validacin de datos, la autenticacin y seguridad o el acceso a datos. Dichos componentes deben trabajar
unos con otros como piezas de un mecanismo, gestionando la informacin que circula entre el usuario y el
servidor de datos.
2005 84
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 ubicacin para los clientes que los utilizan. Ello aumenta mucho la
escalabilidad de las aplicaciones, pues basta con aadir nuevos servidores e instalar los componentes en ellos
para poder atender ms peticiones.
Por otra parte, y esto es muy interesante tambin, mientras sus interfaces de programacin sean las mismas,
es posible sustituir cualquier componente por otro actualizado o que acte de manera distinta para corregir
errores o cambiar el modo de trabajo de la aplicacin global, y todo ello sin que los clientes sean conscientes
de ello. Obviamente esto ofrece ms ventajas an ya que, por ejemplo, no es necesario reinstalar la aplicacin
en cada cliente, sino que basta con sustituir un componente en un nico lugar y automticamente todos los
usuarios tendrn su aplicacin actualizada.
El concepto de Arquitectura Orientada a Servicios o SOA se basa en el uso de este tipo de componentes
que suplen las necesidades de una o varias aplicaciones, son independientes entre s y trabajan
independientemente del sistema operativo o la plataforma.
Aunque muchos programadores piensan que SOA est relacionado nicamente con los Servicios Web lo
cierto es que se pueden conseguir arquitecturas SOA con otras tecnologas.
10.1.2.- Comunicacin entre componentes
Existen diversas dificultades tcnicas a la hora de llevar a la prctica las arquitecturas orientadas a servicios.
Entre stas estn la comunicacin entre las distintas capas y componentes que constituyen la aplicacin, la
gestin de peticiones y el balanceado de carga entre servidores cuando un mismo componente reside en
varios de ellos (para aplicaciones muy grandes con muchos clientes), la gestin de transacciones entre
componentes y algunas otras cosas ms.
Existe la posibilidad de escribir un protocolo de comunicaciones propio que se ocupe de todas estas
cuestiones, pero por supuesto se trata de una opcin muy poco realista dada la complejidad que conllevara.
Para responder a estas necesidades de los programadores, diversos fabricantes y asociaciones de la industria
crearon servicios y protocolos especficos orientados a la interaccin distribuida de componentes. Aunque
existe una gran variedad, de todos ellos los ms importantes sin duda son:
DCOM (Distributed Common Object Model), la propuesta de Microsoft, ligada a sus sistemas
Windows. Se trata de algo ms que un protocolo de invocacin remota de procedimientos (RPC) ya
que su ltima encarnacin, COM+, incluye servicios avanzados para balanceado de carga, gestin de
transacciones o llamadas asncronas. Los parmetros son transmitidos a travs de la red mediante un
formato binario propio llamado NDR (Network Data Representation).
RMI (Remote Method Invocation), es la metodologa de llamada remota a procedimientos de Java. No

se mete demasiado en la definicin de interfaces para compatibilidad binaria de componentes, ni en
otros conceptos avanzados, y se basa en la existencia de un cliente y un servidor que actan de
intermediarios entre los componentes que se quieren comunicar. Es una tecnologa bastante simple
que es fcil de utilizar para aplicaciones bsicas.
CORBA (Common Object Request Broker Architecture). Se trata de una serie de convenciones que
describen cmo deben comunicarse los distintos componentes, cmo deben transferir los datos de
las llamadas y sus resultados o cmo se describen las interfaces de programacin de los
componentes para que los dems sepan cmo utilizarlos. Fue desarrollado por el OMG (Object
Management Group) en la segunda mitad de la dcada de los '90 y es el modelo que ms xito ha
tenido entre los opositores a Microsoft, mayormente en el mundo UNIX. Su mtodo de
empaquetado y transmisin de datos a travs de la red se llama CDR (Common Data representation).
Existen diversas implementaciones de distintos fabricantes e incluso puentes para interactuar con
DCOM.
Estos modelos son buenos y muy eficientes, cumpliendo bien su trabajo pero tienen algunas limitaciones
importantes siendo las principales las siguientes:
2005 85
Es difcil la comunicacin entre los distintos modelos

Su utilizacin a travs de Internet se complica debido a cuestiones de seguridad de las que
enseguida hablaremos.
Existen en el mercado puentes CORBA/DCOM que permiten la comunicacin entre
componentes COM y componentes CORBA, pero su utilizacin es difcil y aaden una nueva
capa de complejidad a las aplicaciones adems de disminuir su rendimiento.
10.1.3.- SOAP
Las expectativas actuales respecto a los componentes han aumentado. Al igual que podemos usar un
navegador web para acceder a cualquier pgina independientemente del sistema operativo del servidor en que
resida, por qu no podramos invocar mtodos de componentes a travs de la red independientemente de
dnde se encuentren, del lenguaje en el que estn escritos y de la plataforma de computacin en la que se
ejecuten?.
Esto es precisamente lo que ofrecen los Servicios Web. Gracias a ellos se derriban las antiguas divisiones
resultantes de los modelos de componentes descritos, y la integracin de las aplicaciones, la ubicuidad de sus
componentes y su reutilizacin a travs de la red se convierten en una realidad.
La tecnologa que est detrs de todo ello se llama SOAP (jabn en ingls). Este acrnimo (Simple Object Access
Protocol) describe un concepto tecnolgico basado en la sencillez y la flexibilidad que hace uso de
tecnologas y estndares comunes para conseguir las promesas de la ubicuidad de los servicios, la
transparencia de los datos y la independencia de la plataforma que segn hemos visto, se hacen necesarios en
las aplicaciones actuales.
10.1.4.- Breve historia de SOAP
SOAP empez como un protocolo de invocacin remota basado en XML diseado por Dave Winer de
UserLand, llamado XML-RPC. A partir de ste se obtuvo en Septiembre de 1999 la versin 1.0 de SOAP, en
la que participo activamente Microsoft y el archiconocido experto en programacin Don Box (ahora
empleado de Microsoft).
Esta primera versin fue ms o menos despreciada por IBM y Sun Microsystems que en esa poca tenan en
marcha un proyecto ms ambicioso llamado ebXML. Esto puso en peligro en su nacimiento la existencia de
SOAP ya que si no todos los grandes lo apoyaban poco se poda hacer. Por fortuna IBM cambi de opinin y
en la actualidad no slo acepta SOAP sino que es uno de lo motores detrs de su desarrollo (Dos importantes
personas de IBM y su filial Lotus, David Ehnebuske y Noah Mendelsohn, son los autores de la especificacin
1.1 de SOAP). Sun Microsystems tambin anunci oficialmente en Junio de 2000 que soportaba el estndar.
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 pequeas empresas de software.
El paso definitivo para asegurar el xito de SOAP y los servicios web es su envo al W3C (World Wide Web
Consortium) para proponerlo como estndar. La ltima versin de la especificacin se puede encontrar en
www.w3.org/TR/SOAP/.
Este soporte mayoritario hace que su xito y pervivencia estn 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 ms avanzados en la adopcin de SOAP.
10.1.5.- La base tecnolgica de SOAP
Lo interesante de SOAP es que utiliza para su implementacin tecnologas y estndares muy conocidos y
accesibles como son XML o el protocolo HTTP.
2005 86
Dado que los mensajes entre componentes y los datos de los parmetros para llamadas a mtodos
remotos se envan en formato XML basado en texto plano, SOAP se puede utilizar para
comunicarse con cualquier plataforma de computacin, consiguiendo la ansiada ubicuidad de los
componentes.
El uso de HTTP como protocolo principal de comunicacin hace que cualquier servidor web del
mercado pueda actuar como servidor SOAP, reduciendo la cantidad de software a desarrollar y
haciendo la tecnologa disponible inmediatamente. Adems en la mayora de los casos se puede
hacer uso de SOAP a travs de los cortafuegos que defienden las redes, ya que no suelen tener
bloqueadas las peticiones a travs del puerto 80, el puerto por defecto de HTTP (de ah otra ventaja,
aunque se pueden usar otros puertos distintos al 80, por supuesto).
La seguridad se puede conseguir a travs de los mtodos habituales en los servidores Web y por tanto se
dispone de autenticacin de usuarios y cifrado de informacin de forma transparente al programador, usando
protocolos y tcnicas como IPSec o SSL, ampliamente conocidos y usados en el mundo Web.
Por otra parte la escalabilidad se obtiene a travs del propio servidor Web o incluso del sistema operativo, ya
que la mayora de ellos (por ejemplo IIS) poseen capacidades de ampliacin mediante clusters de servidores,
enrutadores que discriminan las peticiones y otras tcnicas para crear Web Farms, o conjuntos de servidores
Web que trabajan como si fueran uno solo para as poder atender a ms clientes simultneamente.
Nota:
Existen ampliaciones al protocolo SOAP base que definen protocolos y convenciones para tareas especficas
como las mencionadas de seguridad, enrutado de mensajes, los eventos y muchas otras cuestiones avanzadas.
En .NET se implementan mediante los conocidos Web Services Enhancements (WSE) actualmente por su
versin 3.0, y en un futuro inmediato con Indigo, la nueva plataforma de servicios de comunicaciones de
Windows. El estudio de stos se sale del mbito de este libro.
Como vemos, las tecnologas utilizadas son conocidas y la especificacin SOAP se refiere ms bien a la
manera de usarlas. De este modo las reas cubiertas por la especificacin se refieren a cmo se codifican los
mensajes XML que contienen las llamadas a procedimientos y sus respuestas, y a la manera en que HTTP
debe intercambiar estos mensajes. Si nos referimos a la esencia del estndar, SOAP trata de sustituir a los
diferentes formatos propietarios de empaquetamiento de datos que utilizan otras tecnologas (como DCOM o
CORBA con NDR y CDR respectivamente), as como los protocolos propietarios empleados para transmitir
estos datos empaquetados.
HTTP es el nico protocolo definido en el estndar para SOAP pero ste es lo suficientemente abierto como
para permitir que se empleen otros protocolos distintos para transmitir mensajes SOAP. Por citar unos
pocos, se podra utilizar SMTP (correo electrnico), MSMQ (Microsoft Messaging Queue) para enviar de manera
asncrona las llamadas a procedimientos con SOAP, etc...
10.1.6.- Descubrimiento de servicios: WSDL y UDDI
Otro de los estndares que se definen en SOAP es WSDL (Web Service Definition Language). Se trata de un
formato estndar para describir las interfaces de los servicios web. WSDL describe qu mtodos estn
disponibles a travs de un servicio Web y cules son los parmetros y valores devueltos por stos. Antes de
usar un componente que acta como Servicio Web se debe leer su archivo WSDL para averiguar cmo
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.
Se ha definido tambin un formato estndar para publicacin de informacin de Servicios Web llamado
UDDI (Universal Description Discovery and Integration). Esta especificacin permite la creacin de directorios de
Servicios Web, donde se definen mtodos que permiten consultarlos para encontrar fcilmente aquel servicio
que se necesite. Windows Server 2003 incluye gratuitamente un servidor para implementar directorios UDDI
en organizaciones.
2005 87
10.2.- Creacin de un servicio Web
Tras la teora anterior vamos a ver la manera de llevarla a la prctica construyendo, paso a paso, un Servicio
Web con Visual Web Developer 2005 Express, y comprobaremos lo extremadamente simple que es su
creacin 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.
10.2.1.- Proyectos de servicios Web
Para crear un nuevo proyecto que albergue Servicios Web slo tenemos que utilizar el men ArchivoNuevo
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 10.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 dilogo Agregar nuevo elemento. Sin embargo, lo habitual es
que se guarden en proyectos separados para facilitar su posterior gestin.
10.2.2.- Archivos del servicio Web
Al aceptar se crean para nosotros diversos archivos en el nuevo proyecto,

tal y como se observa en la figura del lateral. stos constituyen el esqueleto
de nuestro servicio.
La extensin asignada a los archivos que representan un servicio Web en

ASP.NET es '.asmx'. En esta figura el archivo Service.asmx es el que
contiene la definicin de nuestro servicio.
2005 88
Si hacemos doble-clic sobre Service.asmx se abre su definicin en el editor de VWD. Lo nico que contiene
es la siguiente lnea:
sta se parece mucho a la directiva de las pginas ASPX y, al igual que en ese caso, define dnde se encuentra
el cdigo que dotar de funcionalidad al servicio Web. En este caso y dado que un 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 definicin de la clase indicada en el atributo Class, y que en nuestro
ejemplo se llama Service.
La clase Service (podra 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 compilacin dinmica de los
archivos de cdigo que contiene.
Si abrimos el archivo Service.vb, veremos que por defecto contiene el siguiente cdigo:
Aparte de las preceptivas sentencias Imports, vemos que la clase Service hereda de la clase WebService.
Slo con hacer esto ya obtenemos la funcionalidad necesaria para gestionar el XML, HTTP y dems
tecnologas en las que se basan los servicios Web. Su gestin pasa inadvertida para nosotros.
Los mtodos que un servicio Web expone al exterior son mtodos normales de una clase a los que se le ha
aadido el atributo WebMethod, tal y como se observa en el cdigo anterior. Es decir, para que uno de
nuestros mtodos 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 mtodo de ejemplo HelloWorld que introduce VWD y escriba el siguiente cdigo:
Ahora disponemos de un mtodo 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 aplicacin independientemente del
lenguaje con el que est construida y del sistema operativo en el que trabaje. Enseguida veremos cmo.
2005 89
Este ejemplo, aunque trivial, puede resultar til en entornos, como los de gestin, en los que la sincronizacin
horaria entre clientes y servidores es fundamental para asegurar la coherencia de facturaciones y otros datos
econmicos.
10.2.3.- 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 (da, mes, ao, hora, minutos y segundos) y adems su formato
depende del idioma definido en el servidor, que no tiene porque ser el mismo que tienen los clientes. Lo ideal
sera obtener una representacin 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 cdigo 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 aplicacin que consuma nuestro servicio.
La especificacin estndar de SOAP define representaciones en formato XML para todos los tipos de datos
bsicos que nos podemos encontrar en las aplicaciones, incluyendo cadenas, fechas, booleanos, etc...
Cualquier clase (o tipo) que se use como parmetro o como valor devuelto por un mtodo que se expondr
en un servicio Web se serializa a XML antes de ser enviada a travs de la red tanto en un sentido como en el
otro (cliente-servidor y viceversa).
Serializar a XML un objeto consiste en generar una representacin de los datos de ste en formato XML de
modo que posteriormente puedan ser deserializados en el otro extremo para obtener un objeto equivalente
al original. En el caso de tipos bsicos la cosa es fcil aunque se debe seguir una convencin para hacerlo. En
el caso de otros objetos ms complejos (como los DataSet, por ejemplo) el formato XML obtenido es mucho
ms complejo y no se encuentra estandarizado, si bien al ser XML y disponer de su esquema es muy fcil
utilizarlos desde cualquier lenguaje.
Como resumen de este prrafo hay que quedarse con una idea: slo se pueden emplear clases
serializables como parmetros o valores devueltos por un mtodo de un servicio Web.
Nota:
Los objetos de la clase DataSet de ADO.NET son objetos serializables que estn adaptados a la perfeccin para
su uso en un servicio Web. De hecho es muy habitual que se utilicen como valores devueltos y como
parmetros en mtodos de servicios Web. Los DataSet tipados tambin se incluyen en esta categora y de
hecho pueden resultar incluso ms sencillos de utilizar cuando el servicio se invoca desde entornos diferentes
a .NET.
10.2.4.- Descripcin de mtodos
El atributo WebMethod no slo se usa para especificar que un mtodo determinado de la clase se expondr
para su consumo desde el exterior. Adems se usa para especificar ciertos comportamientos del mtodo. A
efectos de lo que nos interesa en este libro veremos slo uno de los parmetros de este atributo:
Description.
Con Description ofreceremos a los programadores que consuman nuestro servicio informacin sobre lo
qu hace el mtodo lo que puede ser de gran utilidad. Con ello dejamos nuestro mtodo finalmente definido
como:
Con esto queda definido nuestro sencillo Servicio Web de ejemplo. Enseguida veremos cmo utilizarlo.
2005 90
10.2.5.- Parmetros opcionales y/o sobrecarga de mtodos Web
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 parmetros diferentes.
En una clase .NET podemos crear versiones sobrecargadas de un mtodo cada una de las cuales tomar el
tipo de datos pertinente, siendo el propio compilador el que llamar a la versin sobrecargada que convenga
en cada caso.
En el caso de un Servicio Web a priori puede parecer que no seremos capaces de obtener el mismo efecto, ya
que no podemos exponer dos mtodos Web con el mismo nombre. Sin embargo existe otro parmetro
del atributo WebMethod que permite conseguir un efecto similar. Se trata de MessageName.
MessageName se utiliza para asignar alias a los mtodos Web que definamos, de forma que podemos
identificar de manera nica a cada uno de ellos, incluso aunque el nombre asignado a la funcin sea el mismo.
De este modo, si queremos exponer como servicio Web una clase que posee un mtodo con varias
sobrecargas slo tenemos que emplear este atributo asignndole un identificador diferente a cada una. Por
ejemplo:
Las dos funciones con el mismo nombre y diferentes parmetros son perfectamente vlidas en VB.NET. Sin
embargo si hubisemos colocado simplemente la palabra WebMethod delante de ambas hubisemos obtenido
un error a la hora de compilar ya que no pueden exponerse dos mtodos 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. Con esto conseguimos el efecto de mtodos Web sobrecargados.
10.3.- Examinando manualmente un servicio Web creado con ASP.NET
La manera ms sencilla de examinar un servicio Web creado con ASP.NET es navegando con Internet
Explorer a la URL del archivo .asmx del servicio. En nuestro ejemplo, si navegamos hacia el servicio horario
anterior (basta con pulsar F5 desde VWD para conseguirlo), obtenemos una pgina como la de la figura 10.5.
2005 91
Figura 10.5.- Aspecto de la pgina generada automticamente por ASP.NET
Tal y como comentamos al principio, para que un cliente pueda consumir un servicio Web deber primero
leer el "contrato" de uso del servicio, es decir, averiguar los mtodos que ste ofrece y la forma de
invocarlos. Como recordar este contrato est escrito con el lenguaje WSDL (Web Service Description Language).
Para obtener el WSDL correspondiente a nuestro servicio basta con pulsar sobre el enlace "descripcin de
servicios" que ofrece una pgina auto-generada. El aspecto del WSDL es este (parcial):
Figura 10.6.- WSDL de nuestro servicio Web horario.
Este cdigo XML es el que se utiliza para averiguar los mtodos disponibles y como invocarlos. Como es
bastante tedioso leerlo, ASP.NET simplemente lo procesa por nosotros y genera una bonita pgina Web para
informarnos del contenido del servicio de una forma ms agradable para los humanos. Lo interesante de esta
pgina es que nos permite probar manualmente los mtodos del servicio Web siempre y cuando utilicen
parmetros y valores devueltos sencillos.
Nota:
Esta pgina autogenerada slo 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 depuracin remota, por ejemplo). Sin embargo el WSDL (ruta al servicio Web
seguido de ?WSDL) s es accesible siempre ya que es necesario que otras mquinas lo puedan leer para hacer
uso del servicio.
2005 92
Si pulsamos sobre el mtodo Hora obtendremos una pgina de pruebas que nos permitir invocarlo. Adems
dicha pgina nos ofrece ejemplos de mensajes SOAP de solicitud y respuesta para acceder al mtodo:
Figura 10.7.- Pgina de prueba del mtodo horario. Se ha resaltado una de las solicitudes de ejemplo
facilitadas.
Como vemos las llamadas a la funcin se realizan con XML. Y el resultado?. Obviamente tambin ser
XML. Si pulsamos sobre el botn Invocar obtendremos el resultado en una ventana aparte:
En este caso la invocacin, dado que la hacemos desde el navegador, se realiza mediante un POST HTTP (es
decir, como si envisemos un formulario). El XML devuelto ofrece nicamente el resultado de invocar el
mtodo y al tratarse de una fecha viene codificada de manera independiente al idioma o al sistema operativo,
tal y como define el estndar SOAP.
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 funcin remota.
10.4.- Consumo de servicios Web con ASP.NET
Si crear Servicios Web le ha parecido fcil enseguida comprobar que utilizarlos es incluso ms fcil todava
con ASP.NET.
10.4.1.- Crear un proxy para utilizar el servicio
Cree un nuevo proyecto de aplicacin Web y en la pgina Web por defecto agregue una etiqueta Label1. Esta
etiqueta la usaremos para mostrar la hora en el servidor obtenida mediante el uso del servicio Web creado en
el apartado anterior.
2005 93
Para poder hacer uso del servicio Web debemos aadir una referencia al mismo desde nuestro proyecto. Esto
se consigue pulsando con el botn derecho sobre el nodo del proyecto en el Explorador de soluciones y eligiendo
la opcin Agregar referencia Web:
Figura 10.8.- Agregar referencia web
Al hacer esto se abre un dilogo que nos permite escribir la direccin del WSDL de algn servicio Web
concreto (si nos la sabemos) o buscar servicios Web en diversos lugares.
Figura 10.9.- Buscar servicios web y agregarlos
Podemos buscar servicios en la misma solucin de Visual Web Developer, buscar todos los servicios que
haya instalados en la mquina 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 lnea de direccin URL.
2005 94
Figura 10.10.- Agregar el servicio Web de hora.
Al seleccionarlo se muestran sus mtodos y debemos asignarle un nombre con el que accederemos a su
funcionalidad desde el cdigo. Por defecto el nombre que VWD le otorga es localhost, pero debemos
utilizar algo ms descriptivo, por ejemplo ServicioHora como se ha hecho en la figura.
De manera automtica se aade una nueva carpeta llamada

App_WebReferences y dentro de ella una carpeta por cada
referencia a un Servicio Web que hayamos aadido. Dentro de
esta carpeta hay dos archivos (.disco y .discomap) que contienen
informacin sobre cmo acceder al servicio Web y una copia del
archivo de definicin del servicio Web (.wsdl) que indica a
ASP.NET cmo utilizarlo.
A partir de ahora disponemos de un nuevo espacio de nombres

llamado como la referencia Web (en nuestro caso ServicioHora)
que contiene una clase con el nombre que definimos al crear el
servicio Web (Service en nuestro ejemplo).
As, para utilizar cualquier mtodo del servicio slo debemos

instanciar un objeto de esta clase y llamar al mtodo que nos
interese.
Por ejemplo, para mostrar la hora en el servidor en la etiqueta que hemos aadido a la pgina escribiramos:
Dim sh As New ServicioHora.Service()
Label1.Text = "Hora en el servidor: " + sh.Hora().ToString()
Por supuesto el mtodo Hora devuelve un objeto de la clase Date de VB.NET y podemos utilizar cualquiera
de los mtodos de sta, como por ejemplo ToLongDateString para obtener la expresin larga de la fecha, u
operar con l para ver la diferencia con cualquier otra fecha, etc...
2005 95
Es decir, si alguien aade la referencia Web por nosotros y no nos dice que estamos usando un servicio Web
desde nuestro cdigo no habr diferencia a la hora de usar los objetos expuestos a travs del servicio, si bien
stos pueden estar ejecutndose en otro servidor e incluso en otro pas a travs de Internet.
A la clase auto-generada que representa en local a los objetos expuestos por el servicio web se la denomina
proxy.
Nota:
Hacer uso de este servicio Web desde una aplicacin Windows es igual de fcil que desde una pgina ASP.NET.
Tambin podemos permitir que programadores de otros lenguajes como Java o PHP hagan uso de nuestro
servicio.
10.4.2.- Cambio de ubicacin del servicio
Lo ms habitual es que cuando estamos desarrollando, el servicio y el cliente se encuentren en la misma

mquina. Incluso en caso de no ser as seguramente el servicio que usemos para desarrollo no sea el mismo
que se utiliza luego en produccin, cuando la aplicacin est terminada y usndose en el entorno real. Debido
a ello la referencia que hemos aadido al Servicio Web no ser vlida al poner la aplicacin en produccin y
deberemos hacer que apunte a la referencia web correcta.
La propiedad Url de la clase proxy que se crea para acceder al Servicio Web nos permite establecer en tiempo
de ejecucin la direccin en la que est ubicado el WSDL del servicio que realmente usaremos. ste
obviamente debe ser idntico (su WSDL debe ser idntico) al Servicio Web original que usamos en el
desarrollo.
Por ejemplo si a la hora de poner en produccin la aplicacin de ejemplo el servicio Web reside en un
servidor cuya URL es www.serviciosweb.com escribiramos:

sh.Url = "http://www.serviciosweb.com/servicioHora.asmx"
....
Por supuesto lo habitual es almacenar esta direccin en el archivo web.config para recuperarla en tiempo de
ejecucin y poder variarla fcilmente sin tocar el cdigo.
10.4.3.- Credenciales de acceso
Podemos proteger el acceso a un servicio Web usando los mtodos de autenticacin u autorizacin
proporcionados por Internet Information Server. Si deshabilitamos la autenticacin annima y marcamos la
autenticacin de Windows, para poder acceder al servicio deberemos facilitar credenciales de acceso validas.
stas se corresponden con el nombre de usuario y la contrasea de un usuario del sistema. El cdigo
necesario para hacerlo es el siguiente:

sh.Credentials = New System.Net.NetworkCredential("usuario", "clavesecreta")
....
La propiedad Credentials se usa para enviar las credenciales de cualquier usuario al servidor.
Se pueden usar las credenciales del usuario actualmente autenticado en la aplicacin (sin tener que escribir
nombre de usuario y contrasea alguno) usando la propiedad UseDefaultCredentials del proxy del Servicio
Web:

sh..UseDefaultCredentials = True
....
Con esto obtendremos una barrera de proteccin bsica para nuestro servicio Web.
2005 96
Nota:
Existen una serie de especificaciones adicionales para servicios Web denominadas Web Service Enhancenments
(WSE) que aaden funciones especiales para autenticacin, privacidad, cifrado, enrutado, y otras muchas tareas
avanzadas. Estos WSE siguen las especificaciones conocidas como WS-*, que son un estndar de la W3C y la
nueva plataforma unificada de mensajera de Microsoft, Indigo, tambin las implementa para sus Servicios
Web. El estudio de WSE se sale del mbito de este libro.
2005 97

Manual VWD 2005

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Manual VWD 2005

Enviado por

Direitos autorais:

Formatos disponíveis

Jos Manuel Alarcn Agun

Acerca del autor

En la actualidad es socio de Grupo Femxa, "soluciones al servicio del

CAPTULO 2.- FUNDAMENTOS DEL DESARROLLO DE APLICACIONES WEB 11

CAPTULO 3.- LOS CONTROLES DE ASP.NET 23

CAPTULO 4.- TCNICAS DE TRABAJO Y CONSEJOS VARIOS 33

4.3.- Transferir el control entre pginas 35

CAPTULO 5.- ACCESO A DATOS CON ADO.NET 37

CAPTULO 6.- ACCESO A DATOS CON VISUAL WEB DEVELOPER 2005 51

CAPTULO 7.- MASTER PAGES, TEMAS Y SKINS 59

CAPTULO 8.- ESTADO DE LAS APLICACIONES 68

CAPTULO 9.- SEGURIDAD DE APLICACIONES 74

CAPTULO 10.- INTRODUCCIN A LOS SERVICIOS WEB CON ASP.NET 83

1.1.- El entorno de ejecucin CLR

1.2- El Lenguaje Intermedio y el CLS

1.3.- Cmo se consigue esta potente capacidad?

Un elemento fundamental de la CLR es el compilador JIT (just-in-time). Su cometido es el de compilar bajo

Figura 1.1. Cdigo en lenguaje intermedio obtenido con ILDASM.exe

1.4.- La especificacin comn de los lenguajes y el sistema de tipos comunes

1.5.- La biblioteca de clases de .NET

Figura 1.2. Distintos elementos de la plataforma .NET y cmo se relacionan entre s.

1.6.- Los espacios de nombres

1.7.- Acceso a datos con ADO.NET

1.8.- Arquitectura de ADO.NET

Figura 1.3.- Arquitectura de ADO.NET

Existen dos capas fundamentales dentro de su arquitectura: la capa conectada y la desconectada.

1.8.1.- Capa conectada

1.8.2.- Capa desconectada

1.9.- Aplicaciones Windows Forms

Dim frm As New MiFormulario

1.10.- Aplicaciones Web Forms

En el modelo orientado a eventos se define la interfaz de usuario colocando controles en un contenedor y se

Las principales desventajas de este tipo de codificacin son las siguientes:

1. No existe separacin entre el diseo y la lgica de las aplicaciones. Si queremos cambiar

3. No disponemos de forma de detectar en el servidor que se ha realizado algo en el cliente. El

5. No existe el concepto de Propiedad de los controles. En una aplicacin Windows asignamos el

La principal aportacin de ASP.NET al mundo de la programacin es que ha llevado a la Web el paradigma

Separacin entre diseo y lgica.

Esto como se ver marca un antes y un despus en la programacin para Internet.

2.1.- Las pginas ASPX

Figura 2.1.- Pgina ASPX sencilla

Figura 2.2.- Resultado del cdigo anterior

Figura 2.3.- Ms cdigo aadido a la pgina ASPX

Figura 2.4.- Resultado de la ejecucin.

2.1.2.- Estupendo, pero... en qu hemos mejorado?

2.2.- El entorno de desarrollo: VWD Express 2005

Figura 2.5.- El dilogo de nuevo proyecto web de VWD.

2.2.1.- Explorando el entorno

Tras crear un proyecto nuevo, el entorno tiene un aspecto similar a este:

Figura 2.6.- El entorno de desarrollo de VWD tras crear un proyecto.

2.2.2.- Explorador de soluciones

2.2.3.- rea de documentos

Figura 2.7.- rea de documentos mostrando un editor de HTML.

2.2.4.- Cuadro de herramientas

Figura 2.8.- Cuadro de herramientas y detalle de un algunos grupos de ste.

2.2.5.- Editor de propiedades

Al igual que en Visual Basic 6.0, Frontpage y otros entornos, el editor

Algunas propiedades se editan directamente en el espacio disponible y

2.2.6.- Barras de herramientas y mens

2.3.- Trabajo con formularios Web y controles

2.3.1.- Creando la interfaz grfica del ejemplo

2.3.2.- Respondiendo al evento del botn

Si ejecutamos ahora el ejemplo (pulsando F5 o el botn correspondiente en la barra de herramientas)

Figura 2.11.- Nuestro ejemplo antes y despus de pulsar el botn.