Tag Archives: Teoría

HTML5: SEO y Web Semántica

 

El pasado miércoles 22 de Junio 2011 tuve el placer de asistir a un taller introductorio de HTML5 y CSS3 impartido por Miguel Jiménez en el Aula Vulcan de los amigos de DotNetMania en Madrid.

 

Este pequeño curso tenía el objetivo de mostrar las novedades de HTML5 y CSS3 desde un punto de vista práctico haciendo hincapie en las características y ventajas frente al ya obsoleto modelo de web actual.

 

 

En futuros post iré expicando por encima las principales características de este nuevo lenguaje así que hoy empezamos por uno de los aspectos que me parecieron más importantes: Facilidad para crear una buena Web Semántica.

Una Web Semántica no es más que una página web cuyo código html es facilmente legible y entendible por robots, buscadores y lectores de web. 

Actualmente no se presta mucha atención a este aspecto a menos que tu web tenga que pasar los controles de accesibilidad para ciegos o tenga una alta importancia a nivel de indexación en buscadores. Y es que actualmente la estructura de nuestro código html es caótica, sin relación entre cada elemento y, lo que es peor, desestandarizada ya que cada uno pone lo que quiere.

¿Cómo puede un buscador saber, por ejemplo, qué parte de tu código html es el menú principal o la cabecera? La respuesta es simple: No puede.

Os pongo un ejemplo de una página típica con una cabecera, un menú superior de navegación, un cuerpo, lateral y pie de página. Si somos un poco ordenados podríamos tener una estructura como esta:

<div class="main"> 
 <div class="cabecera"></div> 
 <div class="menu"></div> 
   <div class="cuerpo"> 
       <div class="seccion"></div> 
   </div> 
 <div class="lateral"></div> 
 <div class="pie"></div> 
</div>

Cómo veis tenemos una serie de div para crear nuestros controles y cada uno con su clase css asignada dónde indicamos el tamaño, la posicón, etc… 

Este código a simple vista parece ordenado y se sabe cada div a qué parte de la web corresponde, ¿no? Bueno, a tus ojos si que puede parecerlo pero para un buscador o para un lector de web para ciegos un div con una clase “menu” es lo mismo que “cabecera” o “estilo1”, ¿cómo se supone que debe saber Google dónde está nuestro menú principal así?

Esto es lo que HTML5 resuelve con el uso de etiquetas semánticas para identificar cada uno de estos elementos de forma única e inequívoca: header, nav, article, section, aside y footer (entre otros).

Estos nuevos elementos se muestran en tu navegador como un div con la salvedad de que, al tener un nombre único, los lectores automáticos son capaces de entender que contiene y para que sirven cosa que hasta ahora era imposible.

  • <header> es la etiqueta utilizada para albergar los elementos que forman la cabecera de nuestra web. Tomando como ejemplo esta misma web sería el título “Compilando.ES”, subtítulo y fondo azul de la parte superior.
  • <nav> representa el contenedor de nuestro menú de navegación. Es de vital importancia resaltar este contenedor para que Google pueda generar los enlaces automáticos que aparecen debajo de tu web al buscarla. Por ejemplo:

  • <article> representa un elemento independiente y con sentido propio dentro de la web. El ejemplo es claro, cada post de este blog debería estar embebido en una etiqueta <article>.
  • <section> define una sección dentro del contenedor en el que se anida. Por ejemplo, una <section> en un post de este blog sería el listado de tags al pie.
  • <aside> representa la información que no está directamente relacionada con el resto de la web como la barra lateral con el blogroll o una banner de publicidad.
  • <footer> es el contenedor que alberga los elementos del pie de la página.

 

En nuestro ejemplo usando estas nuevas etiquetas semánticas de HTML5 la cosa quedaría así:

 

<body>
  <header></header>
  <nav></nav>
  <article>
    <section></section>
  </article>
  <aside></aside>
  <footer></footer>
</body>

 

Como veis el código queda más simple y entendible, no solo por ojos humanos si no por los buscadores que ahora ya sabrán dónde buscar los links o que parte de la web corresponde al texto o cabecera.

Además, al tener cada etiqueta un identificador único el estilo CSS se simplifica ya que basta con sobreescribir el estilo del “header” para dar formato a la cabecera sin tener que asignarle una clase con un nombre inventado por nosotros.

 

Espero que el ejemplo haya quedado claro y veais que es muy sencillo cambiar la vieja y desestructurada metodología de divs por esta nueva estructura semántica de HTML5.

Este es el primer artículo de la serie que estoy preparando y espero que os haya resultado últi. Como siempre cualquier duda comentario lo podeis escribir directamente en los comentarios del post.

 

¡¡Nos vemos Compilando!!

Arquitectura MVC, ¿como puede mejorar mi aplicación?

Y es que ultimamente hemos oido mucho hablar sobre MVC pero, ¿qué es realmente y para que se usa? Empecemos desde el principio:

 

MVC son las siglas de Model-View-Controller (Modelo-Vista-Controlador) y es un patrón de la arquitectura del software descrito en 1979 por el Noruego Trygve Reenskaug.

 

El punto principal de MVC es dividir la aplicación en tres capas reales, una para datos, otra para la lógica y otra para la presentación consiguiendo que sea mantenible, escalable y reutilizable.

Para explicar en qué consiste y como funciona vamos a utilizar como ejemplo una hipotética aplicación web .NET que accede a una base de datos SQL SERVER a la que aplicamos este patrón.

  • El “Modelo“, o capa de datos, es el conjunto de clases que representan la información con la que vamos a trabajar y su lógica de negocio. En nuestro ejemplo serían las clases en las que consultamos a la base de datos SQL SERVER mediante, por ejemplo. modelos de Entity Framework.
  • La “Vista“, o capa de presentación, define el modo en el que el usuario ve los datos y como interactúa con ellos. Una página HTML con formularios sería un ejemplo claro de este tipo de capa.
  • El “Controlador“, o capa de lógica, es la que gestiona las peticiones de la Vista solicitando los datos necesarios al Modelo y adaptándolos para su correcta visualización. En .NET serían métodos que actuan como respuesta a un POST de un formulario HTML, captura los datos que el usuario ha introducido y solicita lo necesario al Modelo para retroalimentar la Vista.

 

 

Para terminar de explicar el funcionamiento vamos a platear un formulario de Login en nuestra web de ejemplo.

La Vista sería la página HTML con un <form> con dos <input> uno para el usuario y otro para la contraseña.

Al hacer submit del formulario la petición iría al Controlador que recupera esos datos y solicita al Modelo que busque si el usuario/contraseña introducidos son válidos.

El Modelo realiza la consulta a base de datos y le devuelve el resultado al Controlador que es el que determina si el intento de Login ha sido correcto o no. En caso de ser correcto iniciamos sesión en el sistema y redirijimos a una página de incio del usuario (por ejemplo), en caso de ser erroneo volvemos a la misma vista pero indicando un mensaje de error y el sistema vuelve al punto inicial en el que se espera una acción por parte del usuario.

 

Ventajas de usar MVC

 

  • Escalabilidad

La principal ventaja de separar la aplicación en tres capas reales es la escalabilidad.

Un par de ejemplos: bastaría con recargar el modelo si añades o editas una tabla o crear una nueva vista si quieres hacer una versión para navegador de dispositivo móvil.

  • Simplicidad

Otra gran ventaja es la simplicidad con la que se puede gestionar y mantener el sistema así como la posibilidad de trabajar en paralelo. Puedes tener a diseñadores trabajando en las vistas mientras que los desarrolladores se pueden centrar en el Controlador y el Modelo. ¿Qué quieres cambiar el diseño de la web? Tan solo edita el HTML y la aplicación seguirá funcionando.

  • Desarollo mediante TDD

Al tener la lógica separada de la interfaz es mucho más sencillo crear las pruebas unitarias y desarrollar mediante TDD (Test Driven Development). Sobre esto último dedicaré un artículo más adelante.

  • Rapidez y limpieza de código.

No hay ViewState, ni HTML autogenerado por controles, ni mantenimiento de estado en el código. Lo que interpreta el navegador es exactamente lo que hemos escrito. Eso hace que la página sea más ligera y cargue en menos tiempo.

  • Facilidad para el uso de jQuery

Al tener en la Vista código HTML directamente podemos integrar controles jQuery de forma más sencilla que en WebForms.

 

Conclusiones: ¿WebForms o MVC?

Como habeis podido comprobar en este punto las ventajas de usar este patrón son muchas pero no es oro todo lo que reluce.

MVC es una arquitectura muy compleja que requiere una abstracción mayor por parte del desarrollador que hace que el desarrollo sea más lento por eso solo es recomendable usarlo en ciertos tipos de proyectos.

Si lo que necesitas es hacer un prototipo o RAD, entonces utiliza WebForms.

Si necesitas que la página almacene datos y no quieres estar continuamente haciendo peticiones a la capa de persistencia, entonces utiliza WebForms.

Si tu equipo de desarrollo es pequeño y no trabajais con TDD, entonces utiliza WebForms.

 

En cambio, si tu equipo está segmentado en Diseñadores y Desarrolladores, dispones de conocimientos avanzados de JavaScript y Ajax y necesitas tener un control total del código generado MVC es el patrón que debes utilizar. Si además es un proyecto de cierta embergadura, necesitais controlar mediante pruebas unitarias y va cambiando/ampliandose de forma constante MVC es la solución.

 

Nos vemos Compilando!!

Creando la capa de datos: Entity Framework vs LINQ to SQL

Una de las cosas que más interés me ha generado durante mi vida como desarrollador es como conseguir una buena capa de persistencia, consistente, flexible y transparente para el nivel de aplicación sin mezclar consultas sql’s o crear manualmente clases que repiten funcionalidad y datos.

He trabajado con varias herramientas, desde las más rudimentarias clases estáticas con métodos que ejecutaban sql “a pelo” hasta clases generadas a mano que por debajo usaban una instancia de DataRow (que por cierto no es serializable y no se puede usar con servicios WCF); hasta que en el framework 4.0 de .NET se incluyó el Entity Framework (EF) y LINQ to Entities.

 

Pero antes, un poco de historia:

Ya en la versión 3.5 de .NET nuestros amigos de Redmond incluyeron una nueva herramienta de O/RM (object relational mapping) conocida como “LINQ to SQL”. Con LINQ to SQL podíamos modelar una base de datos relacional con clases .NET de forma automática lo que nos permitia seleccionar, editar, insertar o eliminar datos tan solo editando las clases y colecciones generadas.

Para poder trabajar con estas clases se añadió soporte para lenguaje “LINQ” (Language Integrated Query) que no es más que un modo de expresar consultas similares al sql normal contra cualquier colección (ya sea generado por el modelador de LINQ to SQL o bien creada manualmente). LINQ incluye tipado, comprobación de las consultas en tiempo de compilación, expresiones lambda y tipos anónimos e intellisense lo que lo convierte en un lenguaje para consultas mucho más potente que el sql clásico.

Con estas dos herramientas juntas podemos obtener una serie de clases generadas automaticamente de una base de datos y trabajar con ellas manipulando datos sin necesidad de escribir una sola linea SQL.

 

Más adelante, con la versión 4.0 de .NET se incluyó ADO .NET Entity Framework y su LINQ to Entities que ofrecía una nueva forma de modelar bases de datos en entidades de forma automática más compleja y flexible pero con un funcionamiento básicamente similar ya que también se trabaja mediante consultas LINQ.

 

Visto esto os preguntareis: “Pues tiene buena pinta pero…¿qué diferencias existen entre LINQ to SQL y Entity Framework?

Aunque son casi lo mismo LINQ to SQL y EF han tenido vidas paralelas y, hoy en día, EF se ha impuesto de manera aplastante. La gran diferencia es que LINQ to SQL se creó con la finalidad de ser un RAD (Rapid Application Development) por lo que se dejaron alguna cosas en el tintero que se solventaron con EF:

  • LINQ to SQL sólo permite conectarse a SQL Server y ser usado en C# o VB.NET. EF en cambio soporta varios proveedores como MySql, Oracle, SQL Server, XML, etc…
  • LINQ to SQL mapea cada tabla/vista como una clase o “entidad” sin permitir herencia, entidades lógicas o entidades de negocio. EF lo implementa completamente.

 

Como veis Entity Framewok está preparado para modelar la capa de datos de una forma más generica y flexible lo que nos permite abordar proyectos de mayor envergadura aunque si lo que buscamos es una forma rápida de modelar nuestra base de datos SQL SERVER y no necesitamos grandes florituras LINQ to SQL nos valdría perfectamente.

En futuras entradas explicaré de forma más practica como modelar una base de datos y como hacer las típicas consultas (Select, Insert, Update, Delete) con Entity Framework.

 

Nos vemos Compilando!