Single Page Applications – Parte 2 – Server Technologies (ASP.NET MVC y ASP.NET Web API)

Durante estos posts nos enfocaremos principalmente en el Lado del Cliente (HTML y Javascript) pero de todas maneras necesitamos un Lado del Servidor para trabajar.

Este post lo dedicaremos a implementar el lado del servidor, para esto utilizaremos ASP.NET MVC 4 y ASP.NET Web API, aunque podría ser cualquier otra tecnología de nuestro agrado.

Nota: ASP.NET MVC 4 y ASP.NET Web API actualmente se encuentran en Beta y pueden ser descargados de aquí.

Al aplicar estas tecnologías, el lado del servidor quedaría de la siguiente manera:

dataservices

ASP.NET MVC 4

Utilizaremos esta tecnología para organizar y crear los recursos HTML, Javascript y CSS que luego serán servidos por parte del servidor.

Lo primero que haremos será crear un proyecto ASP.NET MVC 4 en blanco.

newproject

selecttemplate

solutionexplorer

Agregamos la hoja de estilos y modificamos el _Layout.cshtml según el Bakery Template de WebMatrix.

<!DOCTYPE html>
<
html
>
<
head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width" />
    <title>Fourth Coffee -@ViewBag.Title</title>
    <link href="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Content/css")" rel="stylesheet" type="text/css" />
    <link href="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Content/themes/base/css")" rel="stylesheet" type="text/css" />
    <script src="@System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/Scripts/js")"></script
>
</
head
>
<
body>
    <div id="page">
        <div id="header">
            <p class="site-title">
                <a href="~/">Fourth Coffee</a></p>
            <ul id="menu">
                <li><a href="~/">Home</a></li>
                <li><a href="~/About">About Us</a></li>
            </ul>
        </div>
        <div id="body">
            @RenderBody()
       
</div>
        <div id="footer">
            &copy;@DateTime
.Now.Year - Fourth Coffee
       
</div>
    </div
>
</
body
>
</
html
>

Creamos la clase HomeController que retorne la única vista de nuestra aplicación.

public class HomeController : Controller
{
   
public ActionResult
Index()
    {
           
return View();
    }
}

ASP.NET Web API

Nos permite crear y exponer de manera muy simple servicios bajo el protocolo HTTP siguiendo un estilo de arquitectura REST. Algunos de sus beneficios son:
  • Crear servicios REST.
  • Consultas ODATA.
  • Diferentes tipos de formatos: JSON, XML, etc.
  • Soporte de varios elementos ya existentes dentro ASP.NET: Model Binding, Routing, Validation, Filters, etc.
  • Soporte de inyección de dependencias.
  • Fácilmente testeable de manera unitaria.

Mediante ASP.NET Web API implementaremos nuestro Data Services endpoint para exponer servicios que envíen y reciban datos en formato JSON desde el cliente. Para esto realizaremos lo siguiente:

Creamos las clases del modelo para la aplicación y crearemos un DbContext típico de Entity Framework.

public class AppDbContext : DbContext
{
   
public AppDbContext() : base("bakery"
) { }
    public IDbSet<Product> Products { get; set; }
}

Utilizando Nuget agregamos la referencia a AspNetWebApi.Data, luego creamos un controller que herede de AspNetWebApi.Data.DbDataController, los controllers dentro de Web API funcionan de manera muy similar a MVC y permiten exponer servicios HTTP.

También creamos un servicio que devuelva todos los productos en formato JSON.

public class ProductsController : DbDataController<AppDbContext>
{
   
public IQueryable<Product
> Get()
    {
       
return DbContext.Products.AsQueryable();
    }
}

Nota: Retornar los datos como IQueryable y no como IEnumerable permite que se puedan realizar consultas ODATA.

Probamos nuestro servicio levantando toda la aplicación y accediendo a la siguiente URL: http://[domain]/api/products.

image

Esta URL corresponde a nuestro servicio HTTP, debido a que existe la siguiente ruta registrada dentro del Global.asax.

webapiroute

Asimismo, nuestro servicio HTTP dentro del controller tiene el nombre de “Get”, entonces por convención será mapeado automáticamente a todos los GET Request.

Por otro lado el servicio HTTP ha retornado XML, esto se debe a que Chrome envía por defecto en la cabecera de la solicitud Accept: application/xml; si en la cabecera se envía Accept: application/json, el servicio retornaría automáticamente los datos en formato JSON.

Por el momento esto es todo lo que necesitamos implementar en el lado del servidor.

Recursos Adicionales

Hasta el siguiente post.
Saludos.

Single Page Applications – Parte 1 – Definición y Arquitectura

En esta serie de posts veremos los conceptos detrás de las SPAs y como implementar una de estas aplicaciones.

¿Qué son las Single Page Applications?

SPAs son aplicaciones o sitios web que se ejecutan persistentemente sobre la misma página sin necesidad de recargar sin importar como el usuario interactúe.

Son aplicaciones ricas y responsivas que combinan lo mejor de la web y el escritorio, implementadas con Javascript y HTML5.

¿Qué beneficios tienen?

Por qué deberíamos considerar este tipo de aplicaciones:

  • Buena experiencia de usuario.
  • Reducen la carga en el servidor.
  • Similares a las aplicaciones nativas.
  • Pueden trabajar offline.
  • Pueden desplegarse en App-Stores

¿Cuál es su arquitectura?

Una aplicación “multi-page” tradicional usualmente sigue una arquitectura similar a la siguiente:

image 

  • Web UI: Contiene la lógica de negocio y a su vez se encarga de servir recursos HTML, JS, CSS desde el servidor.
  • Visible UI: Renderiza en el navegador la página web.
  • Application Layer: Código Javascript para manipular el comportamiento de la página dentro del navegador.

En cambio una aplicación SPA tiene una arquitectura similar a la siguiente:

image

  • Web UI: Contiene la lógica de negocio y a su vez se encarga de servir recursos HTML, JS, CSS desde el servidor.
  • Data Services: Provee datos en formato JSON o XML desde el servidor.
  • Data Access Layer: Se encarga de solicitar datos al servidor para que estos sean mostrados, enviar datos para que sean procesados.
  • Application Layer: También contiene mucha otra lógica relacionada a Navegación, Binding, etc.
  • Visible UI: También hace uso de templates para renderizar los datos.

¿Cómo implementar una SPA?

En los posts sucesivos veremos detalladamente como implementar una de estas aplicaciones. Como ejemplo utilizaremos el “Bakery Template” que es uno de los templates para construir aplicaciones web que viene por defecto dentro de WebMatrix.

Reutilizaremos su layout y estilos pero reharemos por completo toda la funcionalidad para que funcione como un SPA.

Hasta el siguiente post.
Saludos.