asp.net

LOGO

ASP.NetASP.Net

¿Qué es ASP.Net?

ASP.NET es un framework para aplicaciones web desarrollado y comercializado por Microsoft. Es usado por programadores para construir sitios web dinámicos, aplicaciones web y servicios web XML. Apareció en enero de 2002 con la versión 1.0 del .NET Framework, y es la tecnología sucesora de la tecnología Active Server Pages (ASP). ASP.NET esta construido sobre el Common Language Runtime, permitiendo a los programadores escribir código ASP.NET usando cualquier lenguaje admitido por el .NET Framework.

Características del ASP.Net

Páginas Las páginas de ASP.NET, conocidas oficialmente

como "web forms" (formularios web), son el principal medio de construcción para el desarrollo de aplicaciones web. Los formularios web están contenidos en archivos con una extensión ASPX; en jerga de programación, estos archivos típicamente contienen etiquetas HTML o XHTML estático, y también etiquetas definiendo Controles Web que se procesan del lado del servidor y Controles de Usuario donde los desarrolladores colocan todo el código estático y dinámico requerido por la página web.


Adicionalmente, el código dinámico que se ejecuta en el servidor puede ser colocado en una página dentro de un bloque <% -- código dinámico -- %> que es muy similar a otras tecnologías de desarrollo como PHP, JSP y ASP, pero esta práctica es, generalmente, desaconsejada excepto para propósitos de enlace de datos pues requiere más llamadas cuando se genera la página. ASP.NET Es limitado a solo funcionar con IIS, por lo que su uso es cuestionado por la mayoría de los programadores web quienes prefieren otros lenguajes de programación del lado del servidor como por ejemplo PHP, Perl, Java Etc.

Paginas

Formulario web de ejemplo Este es un ejemplo que utiliza código "en línea",

opuesto al código independiente (code-behind).<%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">

protected void Page_Load(object sender, EventArgs e)

Paginas

{ Label1.Text = DateTime.Now.ToLongDateString();

}

</script>

<html xmlns="http://www.w3.org/1999/xhtml" >

<head runat="server">

<title>Página de Ejemplo</title>

</head>

<body>

<form id="form1" runat="server">

Paginas

<div>

<asp:Label runat="server" id="Label1" />

</div>

</form>

</body>

</html>


El modelo Code-behind Microsoft recomienda que para realizar

programación dinámica se use el modelo code-behind, o de respaldo, que coloca el código en un archivo separado o en una etiqueta de script especialmente diseñada. Los nombres de los archivos code-behind están basados en el nombre del archivo ASPX tales como MiPagina.aspx.cs o MiPagina.aspx.vb (esta práctica se realiza automáticamente en Microsoft Visual Studio y otras interfaces de desarrollo).


Cuando se usa este estilo de programación, el desarrollador escribe el código correspondiente a diferentes eventos, como la carga de la página, o el clic en un control, en vez de un recorrido lineal a través del documento.

El modelo code-behind de ASP.NET marca la separación del ASP clásico y alienta a los desarrolladores a construir aplicaciones con la idea de presentación y contenido separados en mente. En teoría, esto permite a un diseñador web, por ejemplo, enfocarse en la creación del diseño con menos posibilidades de alterar el código de programación mientras lo hace. Esto es similar a la separación en el Modelo Vista Controlador

El Modelo Code-Behind

Ejemplo

<%@ Page Language="C#" CodeFile="EjemploCodeBehind.aspx.cs" Inherits="SitioWeb.EjemploCodeBehind"

AutoEventWireup="true" %> La etiqueta superior es colocada al inicio

del archivo ASPX. La propiedad CodeFile de la directiva @ Page especifica que archivo (.cs o .vb) contiene el código code-behind mientras que la propiedad Inherits especifica la clase de la cual deriva la página.


En este ejemplo, la directiva @ Page está incluida en EjemploCodeBehind.aspx y el archivo EjemploCodeBehind.aspx.cs contendrá el código para esta página:using System;

namespace SitioWeb

{

public partial class EjemploCodeBehind: System.Web.UI.Page

{

protected void Page_Load(object sender, EventArgs e)

{

}

}

}


En este caso, el método Page_Load() será llamado cada vez que la página ASPX sea solicitada al servidor. El programador puede implementar manejadores de eventos en varias etapas del proceso de ejecución de la página..


Controles de usuario ASP.NET permite la creación de componentes

reutilizables a través de la creación de Controles de Usuario (User Controls). Un control de usuario sigue la misma estructura que un formulario web, excepto que los controles derivan de la clase System.Web.UI.UserControl, y son almacenados en archivos ASCX. Como los archivos ASPX, un ASCX contiene etiquetas HTML o XHTML, además de etiquetas para definir controles web y otros controles de usuario. También pueden usar el modelo code-behind.


Los programadores pueden agregar sus propias propiedades y métodos, y manejadores de eventos. Un mecanismo de eventos en burbuja proporciona la capacidad de pasar un evento disparado por un control de usuario a la página que lo contiene.


Administración del estado Las aplicaciones ASP.NET son alojadas en un

servidor web y se tiene acceso a ellas mediante el protocolo sin estado HTTP, que no guarda ninguna información sobre conexiones anteriores. Por lo tanto, si la aplicación requiere interacción entre conexiones, tiene que implementar su propia administración del estado. ASP.NET proporciona varias maneras de administrar el estado de las aplicaciones ASP.NET.

Administración del Estado

Estado de la aplicación

El estado de la aplicación (Application state) es una colección de variables definidas por el usuario que son compartidas por todas las invocaciones de una aplicación ASP.NET. Estos son establecidas e inicializadas cuando el evento Application_OnStart se dispara en la carga de la primera instancia de las aplicaciones y están disponible hasta que la última instancia termina. Las variables de estado de la aplicación son identificadas por nombres.


Estado de la sesión El estado de la sesión (Session state) es una

colección de variables definidas por el usuario, las cuales persisten durante la sesión de un usuario. Estas variables son únicas para diferentes instancias de una sesión de usuario, y son accedidas usando la colección Session. Las variables de sesión pueden ser preparadas para ser automáticamente destruidas después de un determinado tiempo de inactividad, incluso si la sesión no ha terminado. Del lado del cliente, una sesión de usuario es identificada por una cookie o codificando el ID de la sesión en la misma URL.

Estado de la Sesión

ASP.NET proporciona tres modos de persistencia para variables de sesión:

InProc Las variables de sesión son mantenidas dentro

del Proceso (informática). Sin embargo, en este modo, las variables son destruidas cuando el proceso ASP.NET es reciclado o terminado.

SqlServer En este modo, las variables de estado son

almacenadas en un servidor de base de datos, accesible usando SQL. Las variables de sesión pueden persistir a través de finalizaciones de procesos también en este modo.

Estado de la Sesión

StateServer En este modo, ASP.NET ejecuta un servicio de

Windows separado que mantiene las variables de estado. Como esta administración de estado ocurre fuera del proceso ASP.NET, tiene un impacto negativo en el rendimiento, pero permite a múltiples instancias de ASP.NET compartir el mismo estado del servidor, permitiendo que una aplicación ASP.NET pueda tener su carga balanceada y escalada en múltiples servidores. También, como el servicio de administración del estado se ejecuta independiente de ASP.NET, las variables pueden persistir a través de las finalizaciones del proceso ASP.NET.


Estado de la vista El estado de la vista (View state) se refiere al

mecanismo de administración de estado a nivel de página, que es utilizado por las páginas HTML generadas por las aplicaciones ASP.NET para mantener el estado de los controles de los formularios web y los widgets. El estado de los controles es codificado y mandado al servidor en cada envío del formulario en un campo oculto conocido como __VIEWSTATE. El servidor envía de regreso las variables para que cuando la página sea renderizada de nuevo, los controles volverán a su último estado.


Del lado del servidor, la aplicación puede cambiar el estado de la vista, si los resultados del procesamiento actualizan el estado de cualquier control. El estado de los controles individuales son decodificados en el servidor, y están disponibles para su uso en ASP.NET usando la colección ViewState.


Motor de plantillas Al ser liberado, ASP.NET carecía de un motor

de plantillas. Debido a que el .NET framework es orientado a objetos y permite la herencia, muchos desarrolladores podrían definir una nueva clase que herede desde "System.Web. UI.Page", escribir métodos en ella que renderizen HTML, y entonces hacer las páginas en su aplicación que hereden de esta nueva clase. Mientras esto permite que los elementos comunes sean dentro de un sitio, agrega complejidad y mezcla código fuente con lenguaje de marcado.


Además, este método puede ser visto solamente al ejecutar la aplicación, no mientras se está diseñando.

Otros desarrolladores han usado archivos incluidos y otros trucos para evitar la implementación de enlaces de navegación y otros elementos en cada página.

ASP.NET 2.0 presento el concepto de página maestra(Master Page), que permiten el desarrollo de páginas basado en plantillas web. Una aplicación web puede tener una o más páginas maestras, las cuales pueden ser anidadas.


Las plantillas maestras contienen controles contenedores, llamados ContentPlaceHolders para indicar donde ira el contenido dinámico, además de HTML y JavaScript que será compartido a través de las páginas hijas.

Las páginas hijas también usan esos controles ContentPlaceHolder, que deben ser relacionados con el ContentPlaceHolder de la página maestra que contiene a esta página hija. El resto de la página está definido por las partes compartidas de la página maestra. Todo el lenguaje de marcado y controles de servidor en la página de contenido deben ser colocadas dentro del control ContentPlaceHolder.


Cuando una solicitud es hecha por una página de contenido, ASP.NET mezcla la salida de la página de contenido con la salida de la página maestra, y envía el resultado al usuario.

La página maestra permanece completamente accesible a la página del contenido. Esto significa que la página de contenidos puede manipular los encabezados, cambiar el título, configurar la cache, etc. Si la página maestra expone propiedades públicas o métodos, el contenido de la página puede utilizar estos también.


Otros archivos Otras extensiones de archivo asociadas con

las diferentes versiones de ASP.NET incluyen:

ExtensiónVersión

requeridaDescripción

asax 1.0 Global.asax, usada para la lógica a nivel de aplicación

ascx 1.0Controles de usuario web: Controles personalizados para ser colocados en páginas web

ashx 1.0 Manejadores HTTP personalizados

asmx 1.0 Páginas de servicios web


ExtensiónVersión


axd 1.0

Cuando está habilitado en el web.config la solicitud de trace.axd genera trazas de salida a nivel de aplicación. También es usado para el manejador especial webresource.axd que permite a los desarrolladores de controles/componentes empacar un control/componente con imágenes, script, CSS, etc. para el desarrollo de un archivo único (un 'ensamblado')

browser 2.0

Archivos de capacidades del navegador almacenadas en formato XML; introducido en la versión 2.0. ASP.NET incluye muchos de estos por defecto, para admitir a los navegadores web comunes. Estos especifican que navegadores tienen que capacidades, así que ASP.NET 2 puede automáticamente personalizar y optimizar su salida de acuerdo al navegador. Los archivos especiales .browser están disponibles en descarga libre para manejar, por ejemplo, el validador de la W3C. Reemplaza la sección BrowserCaps que se encontraba en el archivo machine.config en ASP.NET 1.x


ExtensiónVersión


config 1.0

web.config es el único archivo en una aplicación web especifica que usa esta extensión por defecto (machine.config tiene efectos similares en un servidor web y todas las aplicaciones en el), sin embargo ASP.NET proporciona la facilidad de crear y utilizar otros archivos config. Son almacenados en formato XML

cs/vb 1.0

Archivos de código fuente (cs indica C#, vb indica Visual Basic). Los archivos code-behind predominantemente tienen la extensión ".aspx.cs" o ".aspx.vb" para los dos lenguajes más comunes. Otros archivos de código (que frecuentemente contienen bibliotecas de clases) pueden también existir en las carpetas web con las extensiones cs/vb. En ASP.NET 2 estos deberían estar colocados dentro de la carpeta App_Code donde son dinámicamente compilados y están disponibles para toda la aplicación


ExtensiónVersión


dbml 3.5 Archivo de clases de datos LINQ a SQL

master 2.0 Archivo de página maestra

resx 1.0

Archivos de recursos para localización y globalización. Los archivos de recursos pueden ser globales (por ejemplo, mensajes) o locales, que están hechos específicamente para un solo archivo aspx o ascx.

sitemap 2.0 Archivos de configuración sitemap

skin 2.0 Archivos de pieles de temas

svc 3.0Archivos de servicio de Windows Communication Foundation


Estructura de directorios En general, la estructura de directorios de

ASP.NET puede ser determinada por las preferencias del desarrollador. Aparte de unos pocos nombres de directorios reservados, el sitio puede expandirse a cualquier número de directorios. La estructura es típicamente reflejada directamente en las urls.

Los nombres de directorios especiales (a partir de ASP.NET 2.0 son):

App_Browsers Contiene archivos de definición específicos para

navegadores.


App_Code Es un directorio para códigos. El servidor ASP.NET

automáticamente compilara los archivos (y subdirectorios) en esta carpeta en un ensamblado que es accesible desde cualquier página del sitio. App_Code es típicamente usada para código de acceso a datos, código de modelo o código de negocios. También cualquier manejador http especifico para el sitio e implementación de módulos y servicios web van este directorio. Como alternativa a utilizar App_Code el desarrollador puede optar por proporcionar un ensamblado independiente con código precompilado.

App_Data Directorio por defecto para las base de datos, tales como

archivos mdb de Microsoft Access y archivos mdf de Microsoft SQL Server. Este directorio es usualmente el único con permisos de escritura en la aplicación.

App_LocalResources Contiene archivos de recursos localizados para páginas

individuales del sitio. App_GlobalResources

Contiene archivos resx con recursos localizados disponibles para cada página del sitio. Este es donde el desarrollador ASP.NET típicamente almacenara mensajes que serán usados en más de una página

App_Themes usado para temas alternativos del sitio.

App_WebReferences Usado para archivos de descubrimiento y archivos

WSDL para referencias a servicios web para ser consumidos en el sitio.

Bin Contiene código compilado (archivos .dll) para

controles, componentes, y otro código que pueda ser referenciado por la aplicación. Cualquier clase representada por código en la carpeta Bin es automáticamente referenciada en la aplicación.

Requisitos de desarrollo de ASP.NET

Para desarrollar aplicaciones ASP.NET, debe tener lo siguiente: .NET Framework 2.0. Un entorno de creación de código. Un servidor Web como IIS (Servicios de Internet

Information Server) y permisos para guardar archivos en el servidor Web.

Si lo desea, puede utilizar los siguientes elementos: Un producto de bases de datos, como Microsoft SQL

Server, para proporcionar el almacenamiento de datos de la aplicación.

Un servidor SMTP para enviar mensajes de correo electrónico de una aplicación Web ASP.NET.


RequisitosEl entorno .NET FrameworkASP.NET forma parte de .NET Framework

como el espacio de nombres System.Web. Para utilizar ASP.NET, debe tener .NET Framework instalado en el equipo que aloja los sitios Web de ASP.NET. Puede descargar la versión 2.0 de .NET Framework del sitio Web .NET Framework Developer Center.


Entornos de creación de código Puede crear clases y páginas ASP.NET utilizando

cualquier editor de texto, como el Bloc de notas de Microsoft, que se suministra con Microsoft Windows. Sin embargo, Microsoft Visual Studio y otros entornos de desarrollo integrados (IDE) proporcionan muchas características de programación, como plantillas de página, IntelliSense, llenado automático de código y compilación en tiempo de diseño. Estas características pueden acelerar el proceso de desarrollo y proporcionar la organización para su proyecto. Para obtener más información sobre Visual Studio, vea Visual Studio Developer Center.


Servidores Web Para trabajar con una aplicación Web

ASP.NET, debe utilizar un explorador para realizar solicitudes al servidor Web que aloja la aplicación. Las aplicaciones Web ASP.NET se alojan normalmente utilizando IIS como servidor Web. Puede probar las aplicaciones ejecutando IIS localmente en el equipo o implementar páginas y componentes en un servidor compartido. Nota Si utiliza Visual Studio, puede probar las

páginas Web de ASP.NET usando el servidor de desarrollo de ASP.NET, que ejecuta las páginas localmente en el equipo sin necesidad de instalar IIS.


Para trabajar con IIS como servidor Web, la cuenta de usuario en la que se realiza la ejecución debe tener permiso de escritura en el directorio en el que reside la aplicación, ya sea como elemento secundario de la raíz del servidor Web (normalmente la carpeta Wwwroot) o como directorio virtual. Observe que la cuenta que requiere permiso para un directorio de aplicaciones suele ser diferente en tiempo de diseño que en tiempo de ejecución. De manera predeterminada, las aplicaciones Web ASP.NET se ejecutan en el contexto de una cuenta de equipo local denominada ASPNET (para Windows 2000 y Windows XP) o en el contexto de la cuenta NETWORK SERVICE (para Windows Server 2003). Para obtener más información, vea Listas de control de acceso (ACL) necesarias para ASP.NET y Configuración de ASP.NET e IIS.


Nota Si tiene IIS instalado, al instalar .NET Framework se registra la extensión ISAPI de ASP.NET (Aspnet_isapi.dll) en IIS. Si instala IIS una vez que.NET Framework está instalado, debe usar la utilidad Aspnet_regiis.exe para registrar ASP.NET con IIS.

Si no puede instalar IIS localmente en su entorno de desarrollo, puede desarrollar su aplicación mediante un servidor Web de IIS compartido. En este escenario, los mismos requisitos de permiso se aplican en el escenario de IIS local.


Bases de datos Si la aplicación implica almacenamiento de

datos, necesita acceso a una aplicación de base de datos como Microsoft SQL Server, y a los permisos adecuados para leer y escribir datos en la base de datos. En los escenarios típicos, una cuenta se utiliza para tener acceso a la base de datos en tiempo de diseño y se utiliza una cuenta diferente para tener acceso a la base de datos en tiempo de ejecución. De manera predeterminada, las aplicaciones Web ASP.NET se ejecutan en el contexto de una cuenta de equipo local denominada ASPNET (para Windows 2000 y Windows XP) o en el contexto de la cuenta NETWORK SERVICE (para Windows Server 2003).


Servidores SMTPPara enviar mensajes de correo

electrónico desde una aplicación Web ASP.NET, la aplicación debe poder reenviar los mensajes a un servidor SMTP. Algunos controles ASP.NET, como el control PasswordRecovery, requieren la capacidad de enviar mensajes de correo electrónico.

Puede utilizar el servidor virtual SMTP de IIS para reenviar mensajes de correo electrónico.

Conexión a una Base de Datos

Conectar con bases de datos en ASP.NET

ASP.NET le proporciona flexibilidad a la hora de conectarse a las bases de datos. Un modo sencillo consiste en utilizar controles de origen de datos, que permiten encapsular el acceso a los datos en un control que se puede configurar con información sobre la conexión y la consulta. Opcionalmente, puede escribir su propio código para realizar el acceso a los datos mediante las clases de ADO.NET.


Utilizar los controles de origen de datos en una página Web ASP.NET Para conectarse a una base de datos mediante un

control de origen de datos, deberá realizar las operaciones siguientes:

Determinar el tipo de control de origen de datos que necesita. Por ejemplo, el control ObjectDataSource funciona con un objeto comercial de nivel medio para recuperar y modificar los datos, mientras que el control SqlDataSource permite proporcionar una conexión a un origen de datos e instrucciones SQL para recuperar y modificar los datos.


Cuando utilice el control SqlDataSource, determine el proveedor que necesita. Un proveedor es una clase que se comunica con un tipo específico de base de datos. El valor predeterminado es el proveedor System.Data.SqlClient, que se conecta a una base de datos de Microsoft SQL Server.

Agregar el control de origen de datos a la página y establecer sus propiedades para el acceso a datos. Por ejemplo, el control ObjectDataSource requiere el tipo de objeto comercial de nivel medio y uno o varios métodos para consultar o modificar los datos. El control SqlDataSource requiere una cadena de conexión que incluya la información que necesita el proveedor para abrir una base de datos determinada y uno o varios comandos SQL para consultar o modificar los datos.


Puede definir la información sobre el proveedor y la conexión como propiedades individuales del control SqlDataSource, o puede definirla de forma centralizada en el archivo Web.config de la aplicación Web. El almacenamiento de la información de conexión en el archivo Web.config permite reutilizarla con varias instancias del control de datos. También ayuda a proteger la información de la cadena de conexión mediante listas de control de acceso (ACL) y cifrado. Para obtener más información, vea "Cadenas de conexión" más adelante en este mismo tema.


Proveedores Un proveedor de ADO.NET es una clase que se puede

comunicar con un tipo específico de base de datos o almacén de datos. Por ejemplo, un proveedor podría comunicarse con una base de datos de SQL Server y otro podría comunicarse con una base de datos de Oracle. Los proveedores incluidos con .NET Framework son:

Proveedor de datos de .NET Framework para SQL Server en el espacio de nombres System.Data.SqlClient. Éste es el proveedor predeterminado para el control SqlDataSource; si se conecta a una base de datos de SQL Server mediante el control SqlDataSource, no es necesario especificar explícitamente un proveedor.


Proveedor de datos de .NET Framework para OLE DB en el espacio de nombres System.Data.OleDb.

Proveedor de datos de .NET Framework para ODBC en el espacio de nombres System.Data.Odbc.

Proveedor de datos de .NET Framework para Oracle en el espacio de nombres System.Data.OracleClient.

El proveedor se puede especificar en el archivo Web.config como parte de una cadena de conexión o como una propiedad de un control de origen de datos individual en una página.


Cadenas de conexión Una cadena de conexión proporciona la información

que un proveedor necesita para comunicarse con una base de datos determinada. Se puede almacenar en el archivo Web.config y hacer referencia a la entrada de configuración en un control de origen de datos.

Dependiendo del proveedor, una cadena de conexión generalmente proporciona el servidor o la ubicación del servidor de bases de datos, la base de datos que se debe utilizar y la información de autenticación. Al igual que ocurre con el proveedor, la cadena de conexión se puede incluir en el archivo Web.config o como una propiedad de un control de origen de datos individual en una página.


Almacenamiento de cadenas de conexión Es recomendable incluir las cadenas de conexión en el

archivo Web.config. En el elemento Elemento <configuration>, se puede crear un elemento secundario denominado <connectionStrings> e incluir allí las cadenas de conexión, como se muestra en este ejemplo:

<connectionStrings> <add name="NorthindConnectionString"

connectionString=" Server=MyDataServer;Integrated Security=SSPI;Database=Northwind;" providerName="System.Data.SqlClient" /> </connectionStrings>


En este ejemplo se proporciona tanto el nombre como el proveedor. Cualquier control de origen de datos situado en cualquier página de la aplicación puede hacer referencia a esta entrada de cadena de conexión. Una ventaja del almacenamiento de la información de cadenas de conexión en el archivo Web.config es que permite cambiar fácilmente el nombre del servidor, la base de datos o la información de autenticación sin necesidad de editar páginas Web individuales. Además, puede proteger la cadena de conexión mediante cifrado. Para obtener más información, vea Cómo: Proteger cadenas de conexión al utilizar controles de orígenes de datos.


Controles de origen de datos Los controles de origen de datos proporcionan servicios

de datos, que incluyen la recuperación y modificación de datos, y pueden utilizar otros controles de servidor Web enlazados a datos, como los controles GridView, FormView y DetailsView. Un control de origen de datos, como SqlDataSource, encapsula todos los elementos requeridos para conectarse a una base de datos (proveedor, cadena de conexión y consulta) y recuperar o manipular los datos. Por ejemplo, el siguiente control SqlDataSource está configurado para conectarse a una base de datos y leer todos los registros de la tabla Customers:


<asp:SqlDataSource ID="SqlDataSource1”

Runat="server“ SelectCommand="Select * from Customers"

ConnectionString="<%$ ConnectionStrings:NorthwindConnectionString %>" />

En este ejemplo, el nombre del proveedor y la cadena de conexión se almacenan en el archivo Web.config, mientras que la consulta SQL está configurada como una propiedad del control de origen de datos.


Realizar el acceso a los datos en el código Si no resulta conveniente utilizar controles de origen

de datos en su aplicación, puede codificar el acceso a los datos con las clases de ADO.NET. Esta práctica es aconsejable si sus requisitos son demasiado complejos para utilizar los controles de origen de datos o si desea crear un componente independiente que realice el acceso a los datos fuera de sus páginas Web.

Características del DataSet - DataReader

Con ADO.NET tenemos dos posibilidades de trabajo: Objetos DataSet. (Clases desconectadas) Objetos DataReader. (Clases conectadas)

Explicaremos sus principales características y diferencias, para tener claro cuando usar uno u otro. Una vez hemos aclarado cual de estos objetos se adapta a nuestras necesidades, explicaremos más detenidamente como debemos trabajar y programar nuestras aplicaciones enlazadas a datos.

En la siguiente figura puedes ver el esquema de objetos utilizado en ADO.NET:


Aplicación ASP.Net

DataSet

Objeto Command

Objeto Conection

Proveedor de Datos

Base de Datos


DataSet. Un objeto DataSet nos permite trabajar con

fuentes de datos y almacenar múltiples tablas. Estas tablas se representan mediante el objeto DataTable. Por lo tanto un objeto DataSet puede trabajar con varias DataTable de modo que pueden existir relaciones entre las DataTable para la recuperación de datos de múltiples tablas.

Visto así parece algo complicado de conseguir, simplemente quédate con la idea de que un DataSet es como una base de datos virtual que se aloja en la propia aplicación. Por lo tanto si hablamos de una base de datos, está claro que podemos contener varias tablas (DataTable) con relaciones entre ellas, para obtener datos.


DataReader Es un objeto mucho más sencillo que un

DataSet, su única función es el acceso a una base de datos para realizar consultas de sólo lectura.

Éstas consultas sólo pueden realizarse hacia delante, es decir, no podremos retroceder para obtener datos anteriores, una vez realizada una consulta en una fila, las anteriores resultan inaccesibles.

Sólo podremos realizar consultas en única base de datos.


Para poder seleccionar correctamente con cual de estos objetos debes optar, debes conocer de antemano que tareas vas a realizar con los datos.

Para realizar consultas de sólo lectura, que únicamente serán necesarias realizarlas una vez (no tendremos que volver a acceder a filas anteriores) el objeto recomendado es DataReader. Por ejemplo, para comprobar si un articulo se encuentra entre una tabla que guarda la lista de artículos del inventario de un almacén, basta con realizar una única consulta de sólo lectura.

Sin embargo, si vamos a realizar un acceso a datos más complicado, como puede ser la consulta de todos los artículos de diferentes tipos que pertenecen a un proveedor, la elección correcta sería utilizar DataSet.


Veamos las ventajas de cada uno de ellos: Acceso a datos.

Como hemos dicho, si tenemos previsto recibir y almacenar datos, optamos por DataSet, ya que DataReader sólo permite lecturas.

Trabajar con más de una tabla o más de una base de datos. Si la función que estamos desarrollando requiere

información situada en varias tablas de una misma base de datos o de varias, utilizaremos el objeto DataSet. Con DataReader sólo podemos construir consultas SQL que accedan a una base de datos.


Controles enlazados. Si únicamente vamos a enlazar un control a nuestros datos,

podemos utilizar DataReader, pero si por el contrario queremos enlazar varios controles a una fuente de datos, el objeto DataSet nos permite crearlo una vez y vincularlo varias. Puede entregar información a tantos controles como deseemos.

Velocidad. El objeto DataSet es más lento que el DataReader, ya que

trabaja en modo desconectado, los datos del DataSet se almacenan en un objeto del servidor. Además, las opciones que ofrece de ejecutar cualquier comando SQL, poder retroceder en las consultas y gestionar varias tablas, provoca una sobrecarga en el servidor. El objeto DataReader al ser mucho más sencillo, resulta también más ligero para el servidor.

Objetos básicos en ASP.Net

SqlClientPermission Permite que el proveedor de datos de .NET

Framework para servidor SQL Server se asegure de que un usuario dispone de un nivel de seguridad suficiente para obtener acceso a un origen de datos.

SqlCommand Representa un procedimiento almacenado o

una instrucción de Transact-SQL que se ejecuta en una base de datos de SQL Server. Esta clase no se puede heredar.

Objetos básicos en ASP.Net

SqlCommandBuilder Genera automáticamente comandos de

tabla única que se utilizan para conciliar los cambios realizados en un objeto DataSet con la base de datos de SQL Server asociada. Esta clase no se puede heredar.

SqlConnection Representa una conexión abierta con una

base de datos de SQL Server. Esta clase no se puede heredar.

SqlDataAdapter Representa un conjunto de comandos de

datos y una conexión de base de datos que se utilizan para rellenar un DataSet y actualizar una base de datos de SQL Server. Esta clase no se puede heredar.

SqlDataReader Proporciona una forma de leer una

secuencia de filas sólo hacia delante en una base de datos de SQL Server. Esta clase no se puede heredar.

SqlParameter Representa un parámetro de un objeto

SqlCommand y, de manera opcional, su asignación a columnas de DataSet. Esta clase no se puede heredar.

asp.net

Documents