Mejores enlaces en ASP.NET

Durante mucho tiempo a la hora de incluir un enlace en mis aplicaciones ASP.NET simplemente utilizaba un control Hyperlink y en su propiedad NavigateUrl escribía la dirección URL. Por ejemplo:

<asp:Hyperlink ID=”ContactLink” runat=”server” NavigateUrl=”~/contact.aspx” Text=”Contacto” />

Este enlace se crea en el navegador como un elemento HTML anchor similar al siguiente:

<a id="ctl00_MainContainer_ContactLink" href="../contact.aspx">Contacto</a>

Este enlace no está tan mal, pero su atributo id es un poco extraño y en este caso particular, como se trata da una URL estática, es innecesario; en consecuencia podríamos evitarlo en pos de lograr un HTML más limpio.

Alguien podría decir: ¿por qué no podemos usar simplemente un elemento HTML anchor en lugar de un control Hyperlink?. Bien, un simple anchor podría estar bien en muchas situaciones:

<a href="/contact.aspx">Contacto</a>

Este enlace funcionaría bien en muchos sitios web, pero trae algunos problemas con los subdominios o subcarpetas. Por ejemplo: si nuestra aplicación ASP.NET está alojada en www.example.com/miapp, el enlace anterior apuntaría incorrectamente a www.example.com/contact.aspx en lugar de www.example.com/miapp/contact.aspx. Es por ello que preferimos usar Hyperlinks y usar el carácter de tilde “~” que nos asegura una URL correcta desde la raíz de nuestra aplicación.

Desafortunadamente no podemos usar la tilde “~” con un simple elemento HTML, pues la tilde se procesa y resuelve en el lado servidor. Un enlace como el siguiente no funcionaría:

<a href="~/contact.aspx">Contacto</a>

Escribiendo enlaces correctos y limpios

Una alternativa para resolver el problema usando el elemento anchor, es usar el método ResolveUrl de la siguiente forma:

<a href=’<%= ResolveUrl(“~/contact.aspx”)’ %>Contacto</a>

Este tipo de enlaces dá como resultado un HTML anchor sin el atributo ID, y funciona correctamente en cualquier sitio con subdominios y es independiente de la estructura de carpetas de nuestro sitio.  El enlace siempre será correcto!. En el navegador se vería como:

<a href="../contact.aspx">Contacto</a>

Mejorando la escritura de los enlaces

Durante un buen tiempo empecé a escribir este tipo de enlaces, pero luego no me sentí muy conforme con la forma de hacerlo. No me parecía muy natural. Otras personas que están aprendiendo ASP.NET les suena complicado o confuso.

Entonces encontré otra forma de lograr el mismo resultado (HTML más limpio y claro), pero de una forma más intuitiva y elegante. El truco consiste en agregar el atributo runat=”server” al elemento HTML anchor y entonces podemos usar el caracter de tilde “~” en el href.

<a href="~/contact.aspx" runat=”server”>Contacto</a>

Esto dá como resultado un enlace HTML limpio y correcto:

<a href="../contact.aspx">Contacto</a>

La buena noticia es que esto podemos aplicarlo también con las imágenes e incluso con los elementos <link> que usamos para referenciar archivos CSS o Javascript en el <head> de nuestras páginas.

Espero les sirva!
Saludos, Gus

 

UPDATE:

Es una costumbre en ASP.NET que al usar controles de servidor proporcionemos un atributo ID al control. Sin embargo, no es obligatorio. Podríamos declarar controles de servidor SIN el atributo ID, como el siguiente:

<asp.HyperLink runat=”server” NavigateUrl=”~/contact.aspx” Text=”Contacto” />

Esto genera en el lado cliente un elemento anchor limpio sin el atributo ID:

<a href="../contact.aspx">Contacto</a>

ADO.NET Entity Framework: The version of SQL Server in use does not support datatype 'datetime2'

Trabajando con ADO.NET EF, en mi entorno de desarrollo tengo SQL Server 2008 y en producción está SQL Server 2005. Al publicar mi aplicación, en algunas páginas obtengo el siguiente error:

The version of SQL Server in use does not support datatype 'datetime2'

SQL Server 2008 dispone de un nuevo tipo de datos Datetime2 que agrega soporte mejorado de fechas y horas.

Por ejemplo, Datetime2 soporta fechas y horas desde 0001-01-01 00:00:00 hasta 9999-12-31 23:59:59.9999999 (nanosegundos de precisión), mientras que el conocido Datetime solo acepta rangos desde 1753-01-01 00:00:00 hasta 9999-12-31 23-59:59.999 (solo milisegundos de precisión). Pueden leer más sobre esto en el siguiente enlace (en inglés): DATETIME2 vs DATETIME in SQL Server 2008

Para resolver el problema de incompatibilidad usando ADO.NET Entity Framework hay que abrir el archivo .edmx con el editor de XML y cambiar el valor del atributo ProviderManifestToken a 2005.

<edmx:Runtime>
<edmx:StorageModels>
   <Schema Alias="Self" Provider="System.Data.SqlClient" ProviderManifestToken="2005">

Luego guardamos los cambios en el modelo y recompilamos la aplicación. Esto resolverá el error de versiones.

Algo importante a saber es que si posteriormente actualizamos el modelo en nuestro entorno de desarrollo el atributo ProviderManifestToken volverá a establecerse al valor 2008 y deberemos cambiarlo manualmente antes de publicar nuestra aplicación.

Quizás con una tarea postbuild podríamos hacer este cambio automáticamente. Si alguien se anima a crear una tarea como esta será bienvenida.

Espero que sirva.
Saludos, Gus

Paginación y Ordenamiento del lado servidor con GridView y ADO.NET Entity Framework

Esta vez quiero mostrarles como actualmente estoy implementando paginación y ordenamiento del lado servidor, usando GridView, ObjectDataSource y ADO.NET EF. Aunque de una forma muy similar también es aplicable a LINQ2SQL.

 

Creando los métodos en la capa de negocio o servicios

El primer paso consiste en crear en nuestra capa de negocios o servicios un par de métodos que luego serán invocados por el control ObjectDataSource.

Básicamente necesito 2 métodos para lograr mi objetivo:

1. Un método que me devuelva la cantidad total de registros
2. Y otro método que me devuelva los registros paginados

Para el ejemplo voy a crear en una clase CatalogService, un método FindProducts() y otro método FindProductsCount().

public IList<Product> FindProducts(int? code, string description, int? categoryID, string sortExpression, int startRows, int maxRows)
       {
           using (var db = new StoreEntities())
           {
               var query = from p in db.Products select p;

               query = FindProductsFilter(query, code, description, categoryID);
               query = FindProductsSort(query, sortExpression);

               return query.Skip(startRows).Take(maxRows).ToList();
           }
       }

Aquí vemos que FindProducts() llamá a 2 métodos FindProductsFilter() y FindProductsSort() que se encargan de aplicar los filtros necesarios y ordenar los registros, y luego usa los métodos Skip y Take para paginar los resultados.

private static IQueryable<Product> FindProductsFilter(IQueryable<Product> query, int? code, string description, int? categoryID)
{
    if (code.HasValue)
        query = query.Where(p => p.Code== code);

    if (!string.IsNullOrEmpty(description))
        query = query.Where(p => p.Description== description);

    if (categoryID.HasValue)
        query = query.Where(p => p.Category.ID== categoryID);

    return query;
}

private IQueryable<Product> FindProductsSort(IQueryable<Product> query, string sortExpression)
{
    if (string.IsNullOrEmpty(sortExpression))
        return query.OrderBy(p => p.Description);

    return query.OrderBy(sortExpression);
}

Es importante saber que el método OrderBy() no acepta un parámetro string para realizar el ordenamiento. Sin embargo, aquí estoy usando unas extensiones de LINQ conocidas como Dynamic Query para lograr este objetivo.

Pueden leer un artículo de Scot Guthrie traducido al español sobre Dynamic Query y descargar el código fuente.

Sin Dynamic Query, tendría que parsear el parámetro sortExpression y escribir un switch o multiples ifs para aplicar el OrderBy correspondiente según el campo. En pocas palabras, tendría que escribir muuucho más código, entonces prefiero Dynamic Query.

Y ahora el método FindProductsCount() que no hace otra cosa más que contabilizar el total de productos. Este método lo utiliza el ObjectDataSource y la grilla para poder calcular el total de páginas necesarias, sin tener que traer todos los registros para luego paginarlos.

public int FindProductsCount(int? code, string description, int? categoryID)
{
    using (var db = new StoreEntities())
    {
        var query = from p in db.Products select p;

        query = FindProductsFilter(query, code, description, categoryID);

        return query.Count();
    }
}

 

Consumiendo los métodos desde la UI

Ahora creo una página aspx con unos campos para filtrar, un botón y una grilla asociada a un ObjectDataSource para los resultados. El formulario se vería mas o menos así:

No deseo explicar cómo enlazar la grilla con un ObjectDataSource, solo bastaría con decir que debemos asociar al método FindProducts() creado anteriormente y asociar los parámetros del método con los controles de la página. Y luego hay que habilitar Paging y Sorting en la grilla.

Las propiedades establecidas para el ObjectDataSource aparecen en negrita:

 

Las propiedades sortExpression, startRows y maxRows serán pobladas y pasadas al método FindProducts y/o FindProductsCount automáticamente.

La última pieza es escribir código para el botón Buscar:

protected void FindButton_Click(object sender, EventArgs e)
{
    if (!Page.IsValid) return;

    try
    {

    ProductsGridView.DataSourceID = ProductsDataSource.ID;
    ProductsGridView.DataBind();
}
catch (Exception ex)
{
    ShowError(ex.Message);
}

}

Debe observarse que solo en runtime estoy enlazando la grilla con el control ObjectDataSource. Es decir, después de configurar la grilla y el ObjectDataSource, en tiempo de diseño, quito la referencia al ObjectDataSource en la propiedad DataSourceID de la grilla. De esta forma, cuando la página se carga no se hace una búsqueda automática, sino solo cuando se completan los filtros de búsqueda y se presiona el botón Buscar.

Pero esto es una particularidad que quise implementar y no tiene ningún efecto sobre la paginación y ordenamiento, motivo de este post.

Bueno creo que ya está todo, ahora hay que probar.

A mí me funcionó de maravillas ;-).

Mirando con el SQL Profiler veo que solo se consultan 10 registros por página. Las consultas al SQL Server devuelven solo los registros que el usuario quiere ver. Esto permite que nuestras aplicaciones sean mucho más escalables, pues solo traemos los registros necesarios y se minimiza la carga de trabajo en la BD.

Bueno espero que sirva.
Comentarios son bienvenidos!

Saludos, Gus

ADO.NET Entity Framework: ¿Cómo actualizar un objeto desconectado?

Un escenario común es el siguiente:

"Al enviar un formulario web, creo una entidad Pedido con los datos proporcionados por el usuario y lo entrego a mi capa de negocios o servicios para que se valide y persista en el almacén de datos."

En este escenario la entidad Pedido enviada desde la página web (o enviada desde un Web Service), se encuentra en estado Deattached. Para que podamos persistir sus cambios necesitamos asociarla a un contexto y luego llamar al método SaveChanges().

Si la entidad aún no existe en el almacén de datos, debemos agregarla. Esto es muy simple, usando los métodos AddTo* generados en el modelo:

context.AddToOrders(order);
context.SaveChanges();

En cambio si la entidad ya existe en el almacén de datos, entonces debemos asociarla al contexto y guardar los cambios. Esta tarea parece ser simple y podríamos intentar resolverla de la siguiente manera:

context.AttachTo("Orders", order);
context.SaveChanges();

Sin embargo, esto no funciona, pues el objeto order se asocia exitosamente al contexto pero en el estado Unchanged. Luego el método SaveChanges() no persiste ningún cambio.

La forma de resolver este problema es recuperando la entidad original desde el almacén de datos, aplicar los cambios, y volver a guardarla.

Buscando en la web encontré diferentes enfoques para resolver este problema. Muchos utilizan Reflection para recorrer todas las propiedades y asignar las que han cambiado. La que más me ha interesado la encontré en el blog de Cesar de la Torre.

Se trata de un extension method llamado AttachUpdated() aplicado al ObjectContext. Me he tomado el atrevimiento de renombrar le método AttacheUpdated() por UpdateObject(), pues me pareció más consistente con otros métodos que ya existen en el ObjectContext como AddObject() y DeleteObject(). El código es el siguiente:

public static void UpdateObject(this ObjectContext context, string entitySetName, EntityObject entity)
{
    var key = context.CreateEntityKey(entitySetName, entity);

    object originalEntity;
    if (context.TryGetObjectByKey(key, out originalEntity))
    {
        context.ApplyPropertyChanges(entitySetName, entity);
        context.ApplyReferencePropertyChanges(entity, (IEntityWithRelationships)originalEntity);
    }
    else
    {
        throw new ObjectNotFoundException();
    }
}

Este método primero crea la EntityKey asociada al objeto usando el método CreateEntityKey() y luego intenta recuperar el objeto desde el almacén de datos usando el método TryGetObjectByKey(). A continuación aplica los cambios usando el método ApplyPropertyChanges() y luego llama al método ApplyReferencePropertyChanges() que se encarga de aplicar los cambios a las entidades relacionadas. Este último método se trata de otro extension method:

private static void ApplyReferencePropertyChanges(this ObjectContext context, IEntityWithRelationships newEntity, IEntityWithRelationships oldEntity)
{
    foreach (var relatedEnd in oldEntity.RelationshipManager.GetAllRelatedEnds())
    {
        var oldRef = relatedEnd as EntityReference;

        if (oldRef != null)
        {
            var newRef = newEntity.RelationshipManager.GetRelatedEnd(oldRef.RelationshipName, oldRef.TargetRoleName) as EntityReference;
            if (newRef != null) oldRef.EntityKey = newRef.EntityKey;
        }
    }
}

Aquí no solo se resuelve el problema de aplicar los cambios a las propiedades del objeto en cuestión sino también los cambios en sus objetos relacionados.

Luego de crear estos extensions methods, el código final para actualizar una entidad desconectada quedaría como:

context.UpdateObject("Orders", order); //Extension method
context.SaveChanges();

He probado esto y funcionó para mí. Espero que también les sea de utilidad.

Saludos, Gus

ADO.NET Entity Framework: ¿Cómo cambiar la ForeignKey de un objeto?

Tengo un formulario de edición de un Producto, y entre muchos otros datos, se debe seleccionar, por ejemplo, la Categoría desde un DropDownList. Al guardar el producto, se debe establecer el ID de la categoría asociada.

La intuición nos llevaría a escribir el siguiente código:

product.Category.Id = Convert.ToInt32(CategoryDropDownList.SelectedValue);

Desafortunadamente, esto provocará un error, porque la propiedad Category es null, o bien porque no se puede cambiar la propiedad Id.

Para resolver el problema podemos escribir lo siguiente:

var categoryId = Convert.ToInt32(CategoryDropDownList.SelectedValue);
product.CategoryReference.EntityKey = new EntityKey("ContosoEntities.Categories", "Id", categoryId);

En lugar de la propiedad Category estamos usando la propiedad CategoryReference y estamos asignando una nueva EntityKey. Esto permitirá que cuando ejecutemos el método SaveChanges, los cambios de la categoría asociada al producto se persistan en el almacén de datos.

Particularmente esta forma de resolver el problema me parece poco intuitiva y elegante. Algo tan simple como cambiar una clave externa implica escribir todo ese código. Sin embargo, hasta ahora, parece ser la única forma de resolver el problema.

Si nos interesa mejorar un poco nuestro código, y escribir algo más simple, podríamos crear una clase Partial de Product, y agregar una propiedad CategoryId:

public int CategoryId
{
   get
   {
       return Convert.ToInt32(CategoryReference.EntityKey.EntityKeyValues[0].Value);
   }

   set
   {
       var qualifiedEntitySet = "ContosoEntities.Categories";
       CategoryReference.EntityKey = new EntityKey(qualifiedEntitySet, "Id", value);
   }
}

Esta propiedad adicional, permitirá escribir algo como:

product.CategoryId = Convert.ToInt32(CategoryDropDownList.SelectedValue);

Muy similar a los que habíamos intentado al principio!

Antes de terminar, alguien podrá decir:

"Usando LINQ TO SQL, estas propiedades se generan automáticamente cuando se crea el modelo."

Es cierto! Pueden dirigir sus comentarios y sugerencias al Blog del Equipo de ADO.NET Entity Framework, y quizás tengamos suerte para la siguiente versión.

Hasta la próxima! Espero que sirva.
Saludos, Gus

ASP.NET Performance Tip: Eliminar HttpModules innecesarios

En cada solicitud de ASP.NET se ejecutan una serie de módulos para completar diferentes tareas. Por ejemplo, el módulo SessionStateModule intercepta cada solicitud, recupera la cookie de sesión  y carga los datos de sesión en el HttpContext. No siempre son necesarios todos los módulos, por ejemplo, si estás usando FormsAuthentication entonces quizás no necesites los módulos de WindowsAuthentication o PassportAuthenticacion.

De forma predeterminada, el archivo machine.config define los siguientes módulos:

<httpModules>

<add name="OutputCache" type="System.Web.Caching.OutputCacheModule" />
<add name="Session" type="System.Web.SessionState.SessionStateModule" />

<add name="WindowsAuthentication"
type="System.Web.Security.WindowsAuthenticationModule" />

<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />

<add name="PassportAuthentication" type="System.Web.Security.PassportAuthenticationModule" />

<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<add name="FileAuthorization" type="System.Web.Security.FileAuthorizationModule" />

<add name="ErrorHandlerModule" type="System.Web.Mobile.ErrorHandlerModule, System.Web.Mobile, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</httpModules>

Los módulos que no utilizamos en nuestra aplicación ASP.NET, podemos removerlos desde el web.config:

<httpModules>
   <remove name="WindowsAuthentication" />
   <remove name="PassportAuthentication" />
   <remove name="AnonymousIdentification" />
   <remove name="UrlAuthorization" />
   <remove name="FileAuthorization" />
</httpModules>

Esto reducirá carga de trabajo innecesaria en cada solicitud ASP.NET, y nuestras aplicaciones estarán un poco más optimizadas.

Pueden encontrar este y otros tips de performance en el siguiente enlace:
http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx

En futuros posts, continuaré sumando más tips de performance, como Compresión Http, Optimización del ViewState, Combinación de Scripts y Css, etc. Incluiré código fuente y herramientas para hacer que nuestras aplicaciones ASP.NET se ejecuten cada vez más rápido.

Espero que sirva.
Saludos, Gus

Session Timeout vs FormsAuthentication Timeout

Muchas veces me preguntan: ¿Cómo hago para aumentar el tiempo de sesión en una aplicación ASP.NET, y evitar que los usuarios vuelvan a la página de login luego de cierto período de inactividad?. Que ya han probado seteando el session timeout en el web.config, setarlo por código, etc. y ASP.NET simplemente ignora esos valores.

Se trata de un tema que ya tiene unos años, pero aún es bastante recurrente y muchas veces confuso. Por ello, he decido postear un poco al respecto.

Para comprenderlo mejor hay que considerar al menos 2 timeout independientes:

1. Session Timeout
2. Forms Authentication Timeout

Session Timeout define cuanto tiempo debe durar la cookie de sesión en el cliente. Cada vez que el usuario navega en el sitio se guarda una cookie de sesión, para identificar las solicitudes del cliente. Esto es independiente de si el usuario se autenticó o no. El valor predeterminado es de 20 minutos, pero puede modificarse con el elemento system.web/sessionState en el web.config:

    <sessionState mode="InProc" timeout="60" />

Forms Authentication Timeout define cuanto tiempo debe durar la cookie de autenticación en el cliente. Expirada la cookie de authenticación el usuario deberá autenticarse nuevamente. El valor predeterminado es de 30 minutos, pero puede modificarse con el elemento system.web/authentication en el web.config:

<authentication mode="Forms">
      <forms loginUrl="~/Security/Login.aspx" timeout="60" />
</authentication>

Siempre complican estas cosas porque uno confunde la sesión con la autenticación. Son dos cosas independientes. Uno puede crear un sitio basado en Forms Authentication sin usar variables de Session, o viceversa, o combinando ambos (lo más común).

Normalmente, no hay problemas con los valores predeterminados de session y authentication, pero en aplicaciones donde el usuario puede pasarse bastante tiempo leyendo o escribiendo hasta finalmente presionar un link o botón, estos valores predeterminados pueden expirar y entonces necesitaremos aumentarlos.

Finalmente, otro timeout que a veces se quiere ajustar es el executionTimeout del elemento HttpRuntine. Este atributo define el tiempo máximo que puede durar la ejecución de una solicitud. El valor predeterminado es 90 segundos, tiempo suficiente para la mayoría de las aplicaciones. Sin embargo, existen escenarios donde se necesita un tiempo mayor, por ejemplo, para subir archivos de gran tamaño. En estos escenarios, seguramente también habrá que aumentar el atributo maxRequestLength. Pueden leer más sobre el tema en Carga de archivos ASP.NET.

Ahora que hay un poco más de luz en el asunto, pueden continuar investigando y profundizar más sobre estos temas.
Espero que sirva.

Saludos, Gus.

Propiedades y métodos públicos en la MasterPage

Este truco ya es un poco viejo, sin embargo, aún puede ser útil para muchos.

En muchas situaciones deseamos exponer propiedades y métodos públicos en la página maestra o página principal para accederlas desde las páginas de contenido. Sin embargo, al hacerlo vemos que no son accesibles. No aparecen en la lista de Intellisense.

Existe una directiva poco conocida llamada MasterType que podemos agregar fácilmente en nuestras páginas de contenido y así poder acceder a las propiedades y métodos públicos definidos en nuestra página maestra.

Una vez definida esta directiva podemos acceder en el código por detrás de nuestras páginas de contenido, a las propiedades y métodos públicos de la MasterPage.

Enjoy it!

¿Cómo recuperar el objeto DataItem del control ListView?

Cada elemento o fila de los controles de datos como GridView, DataList o Repeater disponen de una propiedad DataItem que permite recuperar el registro de datos enlazado a la lista. Esta propiedad es muy útil para procesar los elementos y controles durante el evento de enlace de datos.

Sin embargo, al trabajar con el control ListView incluído en ASP.NET 3.5 habrán notado que no existe una propiedad similar o equivalente para recuperar los datos del ítem enlazado para procesarlos durante el evento ItemDataBound.

Investigando un poco sobre cómo resolver esta ausencia, encontré una forma poco intuitiva:

El truco es que el elemento e.Item de tipo ListViewItem se puede castear a ListViewDataItem y entonces ahí podemos acceder a la propiedad DataItem para luego castearlo nuevamente a la clase de datos que estamos enlazando.

Este doble casting no me agrada mucho, pero es la única forma que encontré para recuperar el elemento de datos que está siendo enlazado al control ListView.

Bueno, espero que sirva y ahorre algunos dolores de cabeza.

Saludos, Gus