Category Archives: ASP.net

[ASP.NET MVC] Iniciando con las plantillas ASP.NET Boilerplate

Hola a todos, una de los temas que más discusión tiene cuando se va a iniciar un proyecto Web es el tipo de aplicación que se va a desarrollar así como la arquitectura sobre la cual se va a construir la aplicación, luego de definir esos puntos comenzamos a crear una estructura básica de nuestra solución, donde generalmente creamos algunos proyectos que casi siempre vamos a utilizar, proyectos y/o componentes como la capa de presentación, el acceso a datos, la lógica de negocio, el dominio y algunos elementos transversales como seguridad, logging, etc.

Adicional a lo anterior, usualmente agregamos algunos componentes/herramientas en cada uno de los proyectos creados con los cuales vamos a trabajar ya sea porque son los que más conocemos, los que más nos gustan, el que esta de moda, en fin, podemos tener un sin fin de motivos para usarlos, algunos de esas herramientas pueden incluir un contenedor de de inyección de dependencias, una herramienta de log para los errores, algunas librerías/framework JavaScript entre otros.

Para solucionar el problema anterior, podemos trabajar con algo que se conoce como plantillas ASP.NET Boilerplate, el cual nos ofrece un marco de trabajo inicial que ya viene con varias características comunes necesarias en la mayoría de los proyectos, así entonces tenemos:

En el lado del servidor:

  • ASP.NET MVC
  • ASP.NET Web API
  • Castle Windsor
  • Log4Net
  • AutoMapper
  • ASP.NET Boilerplate

En el lado cliente:

  • Twitter Bootstrap
  • jQuery
  • jQueryUI
  • jQuery.Validation
  • jQuery.blockUI
  • jQuery.Spinjs
  • Moment.js
  • Modernizr
  • ASP.NET Boilerplate

boilerplate3

Para iniciar a trabajar, debemos ir a la página oficial ASP.NET Boilerplate y lo primero será escoger entre una aplicación de tipo SPA con Angularjs o con Durandaljs (depende lo que más te guste) y una clásica aplicación Web, luego viene la elección del ORM, acá es posible escoger entre Entity Framework o NHibernate, y finalmente el nombre del proyecto, una vez que hemos realizado esos tres sencillos pasos seleccionamos Create My Project:

boilerplate1

Una vez descargo el proyecto, al abrirlo desde Visual Studio vamos a encontrar una aplicación construida que contiene 5 proyectos:

boilerplate2

Y listo, ya tenemos un muy buen punto de partida sobre el cual seguir desarrollando nuestra aplicación, por el momento dejo el post hasta acá, sin embargo publicaré otro sobre como seguir trabajando con este template.

Espero les haya gustado y aprovechen está excelente herramienta, saludos.

[ASP.NET Web API] Routing por atributos en Web API 2

Hola a todos, aunque ya hace un buen tiempo que ha salido la versión 2 de Web API, una de las características que más me ha gustado es el nuevo tipo de routing que tenemos disponible conocido como routing por atributos (attribute routing), el cual básicamente permite definir el routing desde nuestros controladores, además que nos ayuda a solucionar problemas cotidianos que teníamos en versiones anteriores.

Partamos de un sencillo controlador como el siguiente:

public class CustomerController : ApiController
{
	readonly List<Customer> customers = new List<Customer>()
	{
		new Customer() { Id = 1, Name = "Walker", LastName = "Sosa" },
		new Customer() { Id = 2, Name = "Reese", LastName = "Todd" },
		new Customer() { Id = 3, Name = "Jason", LastName = "Woodward" },
		new Customer() { Id = 4, Name = "Samuel", LastName = "Cole" },
		new Customer() { Id = 5, Name = "Harding", LastName = "Mcgowan" }
	};

	public IEnumerable<Customer> Get()
	{
		return customers;
	}

	public Customer GetById(int id)
	{
		return customers.Where(c => c.Id == id).FirstOrDefault();
	}

	public Customer GetByName(string name)
	{
		return customers.Where(c => c.Name.ToLower().Contains(name.ToLower())).FirstOrDefault();
	}
}

Y la clase Customer

public class Customer
{
	public int Id { get; set; }

	public string Name { get; set; }

	public string LastName { get; set; }
}

Ahora si probamos el servicio, tenemos un problema si hacemos una petición del tipo <domain>/api/customer/sam:

routing

Para solucionarlo vamos a aprovechar el nuevo tipo de routing por atributos disponible desde Web API 2 y superior, lo primero entonces es habilitarlo, para ello añadimos la línea config.MapHttpAttributeRoutes(); en el archivo que defina nuestras rutas, generalmente en la carpeta App_Start, clase WebApiConfig, por lo tanto la clase ahora se ve:

public static void Register(HttpConfiguration config)
{
	config.MapHttpAttributeRoutes();

	config.Routes.MapHttpRoute(
		name: "DefaultApi",
		routeTemplate: "api/{controller}/{id}",
		defaults: new { id = RouteParameter.Optional }
	);
}

El siguiente paso es decorar nuestro controlador con el atributo RoutePrefixAttribute, en este caso [RoutePrefixAttribute(“api/customertask”)], este atributo permite definir un nombre diferente al nombre del controlador para ser utilizado:

[RoutePrefixAttribute("api/customertask")]
public class CustomerController : ApiController
{
	...
}

Para los métodos GetById y GetByName usamos el atributo Route:

[Route("{id:int}")]
public Customer GetById(int id)
{
	return customers.Where(c => c.Id == id).FirstOrDefault();
}

[Route("{name:alpha}")]
public Customer GetByName(string name)
{
	return customers.Where(c => c.Name.ToLower().Contains(name.ToLower())).FirstOrDefault();
}

Finalmente nuestro controlador quedaría:

[RoutePrefixAttribute("api/customertask")]
public class CustomerController : ApiController
{
	readonly List<Customer> customers = new List<Customer>()
	{
		new Customer() { Id = 1, Name = "Walker", LastName = "Sosa" },
		new Customer() { Id = 2, Name = "Reese", LastName = "Todd" },
		new Customer() { Id = 3, Name = "Jason", LastName = "Woodward" },
		new Customer() { Id = 4, Name = "Samuel", LastName = "Cole" },
		new Customer() { Id = 5, Name = "Harding", LastName = "Mcgowan" }
	};

	[Route("")]
	public IEnumerable<Customer> Get()
	{
		return customers;
	}

	[Route("{id:int}")]
	public Customer GetById(int id)
	{
		return customers.Where(c => c.Id == id).FirstOrDefault();
	}

	[Route("{name:alpha}")]
	public Customer GetByName(string name)
	{
		return customers.Where(c => c.Name.ToLower().Contains(name.ToLower())).FirstOrDefault();
	}
}

Luego de los cambios, las siguientes llamados funcionan sin problema:

  • http://<domain>/api/customertask -> Método Get()
  • http://<domain>/api/customertask/2 -> Método GetById(int id)
  • http://<domain>/api/customertask/sam -> Método GetByName(string name)

Si quieren profundizar en el tema les recomiendo el siguiente link: Attribute Routing in Web API 2

Espero les sea de utilidad, saludos!

[ASP.NET] Subiendo archivos a un blob storage con RadCloudUpload

Hola a todos, actualmente es muy común que en las aplicaciones Web el cargue de archivos se haga a un storage en la nube, y generalmente es necesario crear todo el código para implementar dicha funcionalidad, sin embargo Telerik nos hace la vida más sencilla ya que en su gama de controles ahora disponemos de RadCloudUpload, control que en esencia nos permite realizar la subida de un archivo a un storage en la nube (Azure, Amazon S3 y Telerik Backend Services).

Pues bien, su implementación es bastante sencilla y la vamos a realizarm para cargar archivos a un blob storage de Microsoft Azure, una vez añadimos el control, como es costumbre tenemos algunas opciones para comenzar su parametrización como:

  • Tamaño del archivo
  • Proveedor del storage
  • Extensiones permitidas
  • Posibilidad de subir múltiples archivos
  • Skin

cloudupload1

Como hemos seleccionado en el proveedor Azure, se habilita un wizard para ingresar los datos del storage:

cloudupload3

No olvides agregar por Nuget el paquete Windows Azure Storage:

cloudupload2

Y listo, ya es solo probar, una vista previa del control funcionando:

cloudupload4

Si luego requieren cambiar los datos del storage, todos los datos se han replicado en el web.config:

<telerik.web.ui>
	<radCloudUpload>
	  <storageProviders>
		<add name="Azure" type="Telerik.Web.UI.AzureProvider" 
			 accountKey="681o+9PweN+2k....." 
			 accountName="demomvcsignalr" 
			 blobContainer="democloudupload" 
			 ensureContainer="true" 
			 uncommitedFilesExpirationPeriod="1" 
			 defaultEndpointsProtocol="" />
	  </storageProviders>
	</radCloudUpload>
</telerik.web.ui>

Saludos!

[ASP.NET] Integrando ASP.NET con Telerik ASP.NET AJAX

Hola a todos, muchos sabrán de mi gusto por los controles y herramientas de Telerik, así que quiero comenzar a compartir regularmente post sobre sus productos. En esta ocasión vamos a ver cómo es de sencillo integrar los controles ASP.NET AJAX en una aplicación nueva de tipo Web Forms, tarea que Telerik nos pone bastante fácil (con un wizard :)).

Una vez ya tienes instalados los controles, y te recomiendo utilices el Telerik Control Panel (luego hablamos hablaremos de él), tenemos un template que nos va a llevar paso a paso:

Primero seleccionamos el template Telerik Web Application:

telerik 1

Luego se abre un wizard en donde podemos configurar algunas partes importantes del proyecto, iniciando con el tema a utilizar y si se desea agregar una referencia de los assemblies a la solución:

telerik 2

En el siguiente paso es posible establecer algunas opciones, como por ejemplo si usar CDN entre otras:

telerik 3

Luego si queremos tener soporte para jQuery y templates:

telerik 4

Y finalmente si queremos usar Telerik Data Access, el ORM de Telerik (que la verdad va bastante bien):

telerik 5

Y listo, ya solo queda usar y aprovechar la potencia de los controles!

Saludos!

[ASP.NET Web API] Web API IX – Consumiendo un servicio externo, CORS

Hola a todos, hoy vamos a retomar la serie de post sobre Web API, para hablar específicamente el como podemos consumir dichos servicios pero de un dominio diferente, lo primero que vamos a realizar es desplegar lo que se ha venido trabajando, y lo he hecho ayudandome de Azure y en un par de clicks ya esta listo: http://testwebapi.azurewebsites.net, ahora el siguiente paso es crear un cliente para consumir dicho servicio (que ya todos conocemos), para este caso he replicado lo que hemos venido trabajando, la diferencia es que en el archivo person.js al realizar el llamado al servicio ahora es necesario utilizar el dominio del sitio:

http://testwebapi.azurewebsites.net/api/person/...

Bueno, hasta el momento todo parece listo, entonces si probamos vamos a obtener el siguiente error:

error domain

Revisando el error, podemos deducir que el problema se da porque estamos realizando la petición entre dominios diferentes, y es acá donde iniciamos a hablar de CORS!

CORS que quiere decir algo como intercambio de recursos entre dominios cruzados (Cross-Origin Resource Sharing, si mucho mejor la definición en inglés) lo que hace es definir un modelo para poder acceder a recursos de diferentes dominios, en ese caso tanto el cliente como el servidor digamos que trabajan de la mano usando encabezados HTTP.

Cuando estamos usando el método GET para la petición, en la cabecera del request se envía la propiedad Origin con el dominio desde el cual estamos realizando la petición, luego el servicio Web API válida si el dominio que realiza la petición es permitido, en caso afirmativo en la cabecera de la respuesta en la propiedad Access-Control-Allow-Origin se retorna el mismo dominio que realizo la petición o un * para permitir todos los dominios, si la respuesta no cumple esa condición el browser elimina la respuesta:

request 1

Y ahora la solución, nos vamos al método Get del servicio y en el header de la respuesta le agregamos la propiedad Access-Control-Allow-Origin con el valor *, o bien si se tiene un listado de dominios permitidos allí hacer la validación y retornar el dominio específico en lugar del *, por lo tanto el código quedaría:

public HttpResponseMessage GetPerson()
{
	var data = db.Person.AsEnumerable();

	var httpResponseMessage = Request.CreateResponse&lt;IEnumerable&lt;Person&gt;&gt;(HttpStatusCode.OK, data);
	httpResponseMessage.Headers.Add(&quot;Access-Control-Allow-Origin&quot;,&quot;*&quot;);

	httpResponseMessage.Headers.CacheControl = new CacheControlHeaderValue()
	{ 
		MaxAge = TimeSpan.FromMinutes(1)
	};

	return httpResponseMessage;
}

[ActionName(&quot;getbyid&quot;)]
public HttpResponseMessage GetPerson(Int32 id)
{
	var person = db.Person.Find(id);

	if (person == null)
	{
		var httpResponseMessage = Request.CreateResponse&lt;Person&gt;(HttpStatusCode.NotFound,person);
		httpResponseMessage.Headers.Add(&quot;Access-Control-Allow-Origin&quot;, &quot;*&quot;);

		return httpResponseMessage;
	}
	else
	{
		var httpResponseMessage = Request.CreateResponse&lt;Person&gt;(HttpStatusCode.OK, person);
		httpResponseMessage.Headers.Add(&quot;Access-Control-Allow-Origin&quot;, &quot;*&quot;);

		return httpResponseMessage;
	}
}

Ahora si probamos de nuevo la petición Get funciona correctamente:

response

Bueno, ya tenemos el GET, ahora vamos a trabajar con los demás verbos Http, por ejemplo si intentamos realizar una petición PUT obtenemos:

put

Revisando la información del request, tenemos dos cosas importantes, la primera es que en Request Method el valor es OPTIONS y la segunda que el Status Code es el 405 (Método no permitido), bueno y ahora? Lo que debemos hacer ahora es leer el encabezado de la petición y hacer algunas pequeñas adiciones como especificar que se permitan los verbos PUT y DELETE, permitir todos los dominios y aceptar en el header el atributo Content-Type, para este caso, vamos a crear un Message Handler con el nombre RequestMethodHandler:

public class RequestMethodHandler : DelegatingHandler
{
	protected override async Task&lt;HttpResponseMessage&gt; SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
	{
		if (request.Headers.Contains(&quot;Origin&quot;) &amp;&amp; request.Method == HttpMethod.Options)
		{
			var response = new HttpResponseMessage(HttpStatusCode.OK);
			response.Headers.Add(&quot;Access-Control-Allow-Origin&quot;, &quot;*&quot;);
			response.Headers.Add(&quot;Access-Control-Allow-Methods&quot;, &quot;PUT, DELETE&quot;);
			response.Headers.Add(&quot;Access-Control-Allow-Headers&quot;, &quot;Origin, X-Requested-With, Content-Type, Accept&quot;);
			return response;
		}

		return await base.SendAsync(request, cancellationToken);
	}
}

y no olviden llamarlo en WebApiConfig:

config.MessageHandlers.Add(new RequestMethodHandler());

Ahora replicamos los cambios que realizamos en el método GET del controlador para los demás métodos que tenemos allí (POST, UPDATE, DELETE), por lo que ahora el controlador quedaría:

public class PersonController : ApiController
{
	private PersonDBContext db = new PersonDBContext();

	/// &lt;summary&gt;
	/// Get all persons
	/// &lt;/summary&gt;
	public HttpResponseMessage GetPerson()
	{
		var data = db.Person.AsEnumerable();

		var httpResponseMessage = Request.CreateResponse&lt;IEnumerable&lt;Person&gt;&gt;(HttpStatusCode.OK, data);
		httpResponseMessage.Headers.Add(&quot;Access-Control-Allow-Origin&quot;,&quot;*&quot;);

		return httpResponseMessage;
	}
	
	[ActionName(&quot;getbyid&quot;)]
	public HttpResponseMessage GetPerson(Int32 id)
	{
		var person = db.Person.Find(id);

		if (person == null)
		{
			var httpResponseMessage = Request.CreateResponse&lt;Person&gt;(HttpStatusCode.NotFound,person);
			httpResponseMessage.Headers.Add(&quot;Access-Control-Allow-Origin&quot;, &quot;*&quot;);

			return httpResponseMessage;
		}
		else
		{
			var httpResponseMessage = Request.CreateResponse&lt;Person&gt;(HttpStatusCode.OK, person);
			httpResponseMessage.Headers.Add(&quot;Access-Control-Allow-Origin&quot;, &quot;*&quot;);

			return httpResponseMessage;
		}
	}

	/// &lt;summary&gt;
	/// Get a person by an id
	/// &lt;/summary&gt;
	/// &lt;param name=&quot;id&quot;&gt;&lt;/param&gt;
	/// &lt;returns&gt;&lt;/returns&gt;
	[ActionName(&quot;getbyotherid&quot;)]
	public Person GetPersonByOtherId(Int32 id)
	{
		Person person = db.Person.Find(id);
		if (person == null)
		{
			throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.NotFound));
	}

		return person;
	}

	// PUT api/Person/5
	public HttpResponseMessage PutPerson(Int32 id, Person person)
	{
		HttpResponseMessage response;

		if (!ModelState.IsValid)
		{
			response = Request.CreateResponse(HttpStatusCode.BadRequest, ModelState);
		}
		else if (id != person.Id)
		{
			response = Request.CreateResponse(HttpStatusCode.BadRequest);
		}
		else 
		{
			db.Entry(person).State = EntityState.Modified;

			try
			{
				db.SaveChanges();
				response = Request.CreateResponse(HttpStatusCode.OK);
			}
			catch (DbUpdateConcurrencyException ex)
			{
				response = Request.CreateResponse(HttpStatusCode.NotFound, ex);
			}
		}
		
		response.Headers.Add(&quot;Access-Control-Allow-Origin&quot;, &quot;*&quot;);
		return response;
	}

	// POST api/Person
	public HttpResponseMessage PostPerson(Person person)
	{
		if (ModelState.IsValid)
		{
			db.Person.Add(person);
			db.SaveChanges();

			HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.Created, person);
			response.Headers.Location = new Uri(Url.Link(&quot;DefaultApi&quot;, new { id = person.Id }));
			response.Headers.Add(&quot;Access-Control-Allow-Origin&quot;, &quot;*&quot;);
			return response;
		}
		else
		{
			return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
		}
	}

	// DELETE api/Person/5
	public HttpResponseMessage DeletePerson(Int32 id)
	{
		Person person = db.Person.Find(id);
		HttpResponseMessage response;

		if (person == null)
		{
			response = Request.CreateResponse(HttpStatusCode.NotFound);
		}
		else
		{
			db.Person.Remove(person);

			try
			{
				db.SaveChanges();
				response = Request.CreateResponse(HttpStatusCode.OK, person);
			}
			catch (DbUpdateConcurrencyException ex)
			{
				response = Request.CreateResponse(HttpStatusCode.NotFound);
				
			}
		}

		response.Headers.Add(&quot;Access-Control-Allow-Origin&quot;, &quot;*&quot;);
		return response;
	}

	protected override void Dispose(bool disposing)
	{
		db.Dispose();
		base.Dispose(disposing);
	}
}

y si probamos de nuevo, podemos ver que ahora si todo nos funciona correctamente.

Espero este post les sirva bastante, saludos!

Descarga el ejemplo!

[ASP.NET Web API] Web API VIII – Trabajando con los ActionName

Hola a todos, volviendo con la serie sobre ASP.NET Web API, en esta oportunidad quiero mostrarles como podemos personalizar el nombre de las acciones y además poder tener dos o más métodos que trabajen con el mismo verbo HTTP y una misma firma.

Para personalizar el nombre de las acciones, es necesario decorar cada acción con el atributo ActionName y especificar el nombre que deseamos utilizar:

[ActionName(&quot;nombre_de_la_acción&quot;)]

Para nuestro ejemplo vamos a crear una nueva acción con el nombre GetPersonByOtherId(Int32 id), dicha acción obedece al verbo Http Get y tiene la misma firma que la acción GetPerson, adicionalmente decoramos las acciones con el atributo ActionName y le asignamos un nombre (si en este caso la lógica de cada acción es la misma):

[ActionName(&quot;getbyid&quot;)]
public Person GetPerson(Int32 id)
{
	Person person = db.Person.Find(id);
	if (person == null)
	{
	   throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.NotFound));
	}

	return person;
}

[ActionName(&quot;getbyotherid&quot;)]
public Person GetPersonByOtherId(Int32 id)
{
	Person person = db.Person.Find(id);
	if (person == null)
	{
		throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.NotFound));
	}

	return person;
}

Adicionalmente agregamos un nuevo elemento en nuestro HTML:

&lt;input id=&quot;btnSearch2&quot; type=&quot;button&quot; value=&quot;Search by Other Id&quot; data-bind=&quot;click:getPersonByOtherId&quot; /&gt;

Ahora modificamos el ViewModel y agregamos la función getPersonById, así como en la función getPersonById hacemos un pequeño cambio a la url que se esta llamando, en este caso agregando el nombre de la acción:

...
self.getPersonById= function () {
	var url = '/api/person/getbyid/' + self.id();
	$.getJSON(url)
		.done(function (data) {
			self.name(data.Name);
			self.lastname(data.LastName);
			self.twitter(data.Twitter);
		})
		.fail(function (erro) {
			self.clearForm();
	});
},

self.getPersonByOtherId = function () {
	var url = '/api/person/getbyotherid/' + self.id();
	$.getJSON(url)
		.done(function (data) {
			self.name(data.Name);
			self.lastname(data.LastName);
			self.twitter(data.Twitter);
		})
		.fail(function (erro) {
			self.clearForm();
		});
},
...

Luego es necesario agregar una nueva ruta en la tabla de routing, en este caso en la clase WebApiConfig:

config.Routes.MapHttpRoute(
	name: &quot;ApiByOtherId&quot;,
	routeTemplate: &quot;api/{controller}/{action}/{id}&quot;,
	defaults: new { id = RouteParameter.Optional }
);

Y ahora si ejecutamos y probamos podemos ver como en efecto los ActionName funcionan correctamente:

ActionName

Espero el post les haya gustado, hasta el próximo!

Descarga el ejemplo!

[ASP.NET Web API] Web API VII – Message Handlers

Hola a todos, luego una pequeña ausencia, retomo el blog con un nuevo artículo sobre Web API, en este caso tratando el tema de los Message Handlers, un Message Handler se ejecuta antes que cualquier action filter además que son ejecutados para todos las acciones de los controladores, por lo anterior, un Message Handler es ideal para tener lógica centralizada que se deba ejecutar en cada request.

Como parte informativa, el primer Message Handler que se ejecuta es el HttpServer, y luego si se ejecutarán los que nosotros definamos.

Para crear un Message Handler personalizado, se debe crear una clase que herede de DelegatingHandler y sobrescribir el método SendAsync, generalmente los Message Handler son utilizados para temas como autenticación y autorización.

En nuestro caso, vamos a implementar un Message Handler que valide el dominio desde el cual están realizando la petición, para autorizarla o no, lo primero es crear una nueva clase a la que llamaremos ValidationHandler y como ya se comento dicha clase heredara de DelegatingHandler:

public class ValidationHandler : DelegatingHandler
{
	protected override async Task SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
	{
		var domain = &quot;localhost&quot;;
		if (!string.Equals(request.RequestUri.Host, domain, StringComparison.OrdinalIgnoreCase))
			return request.CreateResponse(HttpStatusCode.Unauthorized);

		var response = await base.SendAsync(request, cancellationToken);
		return response;
	}
}

Allí, accedemos al valor del host que realiza la petición por medio del objeto request que es del tipo HttpRequestMessage, en caso que el host no sea válido se crea al vuelo la respuesta a la petición y se retorna un código 401 que indica no autorizado (HttpStatusCode.Unauthorized).

Finalmente para que el Message Handler entre en ejecución, se debe relacionar en el Application_Start, y recuerden que tenemos una clase llamada WebApiConfig donde se tiene configurado el routing para Web API, por lo tanto es un buen lugar para relacionarlo, recuerda tener presente el orden en que se añaden, ya que en ese mismo orden serán ejecutados:

public static void Register(HttpConfiguration config)
{
	...
	config.MessageHandlers.Add(new ValidationHandler());
}

no autorizado

Espero les haya gustado el post, ya nos seguiremos viendo por acá con otras entregas sobre Web API.

Descarga el ejemplo!

[ASP.NET Web API] Web API VI – Implementando Caché

Hola a todos, vuelvo con otro post sobre Web API, en esta ocasión quiero mostros como podemos implementar un sencillo sistema de caché para reducir las peticiones que se realizan a nuestro servicio y así poder mejorar el rendimiento del mismo, para el ejemplo implementaremos dicho sistema en la acción que retorna todo el listado de personas, recordando tenemos algo como:

public IEnumerable<Person> GetPerson()
{
	var data = db.Person.AsEnumerable();
	return data;
}

La acción anterior simplemente consulta la fuente de datos y los retorna, sin embargo este tipo de comportamientos puede traernos problemas futuros ya que constantemente se está consultando la fuente de datos para traer todos los registros existentes y si dicha fuente de datos es una base de datos se debe tener presente el abrir y cerrar conexiones, el delay entre que se lanza el query y el momento en que el servidor de base de datos responde… ya vemos por donde va todo no?

Pensando en el problema anterior, una solución es implementar un sistema de caché para reducir las peticiones a la base de datos y en algunos casos (como este) también disminuir los request al servicio. Lo primero es añadir un nuevo botón que realice la petición a la acción GetPerson() para ver su comportamiento:

<input type="button" id="btnGetAll" value="Get all" data-bind="click:getAll" />;

Ahora probamos de nuevo la aplicación y para ver el comportamiento damos click varias veces en el botón creado anteriormente, con ayuda de firebug revisemos las peticiones:

firebug1

y el detalle de alguna de ellas:

no-cache

Resumiendo la prueba, cada vez que damos click en el botón se realiza una nueva llamada al servicio, y como se aprecia en el detalle de la petición, en el Header de la respuesta el Cache-Control tiene el valor no-cache, que como adivinan indica que no se está manejando.

Para aplicar caché, vamos a hacerle un refactoring a la acción GetPerson() teniendo en cuenta los siguientes puntos:

  • Se retornará HttpResponseMessage en lugar de IEnumerable<Person>.
  • Se definirá la caché en el header de la respuesta.

Con los dos puntos anteriores en mente, ahora la acción GetPerson() quedaría:

public HttpResponseMessage GetPerson()
{
	var data = db.Person.AsEnumerable();

	var httpResponseMessage = Request.CreateResponse<<IEnumerable<Person>>(HttpStatusCode.OK, data);

	httpResponseMessage.Headers.CacheControl = new CacheControlHeaderValue()
	{
		MaxAge = TimeSpan.FromMinutes(1)
	};

	return httpResponseMessage;
}

Lo primero es obtener los datos, luego se crea el objeto HttpResponseMessage, se define el tipo de dato que se retornará, en este caso un IEnumerable<Person>, el código de la respuesta es 200 (HttpStatusCode.OK) y los datos; y ahora para especificar el uso y tiempo de vida de la cache, modificamos el valor de la propiedad CacheControl del header y definimos que su tiempo de vida será de 1 minuto.

Si ahora repetimos la prueba realizada, y damos click varias veces seguidas en el botón para obtener todos los datos, visualizamos que ya no se realizan tantas peticiones como clicks,  ya que la caché usada guarda los datos en JSON en el cliente y los utiliza cada vez que hacemos click, claro que una vez se complete 1 minuto, la siguiente petición SI se realizará normalmente y se volverá a cachear la respuesta, y para que no quede duda, revisemos de nuevo la información de la petición y su respuesta con firebug, la propiedad Cache-Control ahora tiene el valor max-age=60, es decir que usa caché con un duración de 60 segundos.

si-cache

Espero e post les haya gustado, nos vemos!

Saludos!

Descarga el ejemplo!

[ASP.NET Web API] Web API V – Filtros de acción

Hola a todos, de nuevo con otro post de la serie de ASP.NET Web API, esta vez vamos a revisar como podemos crear filtros de acción los cuales nos permiten ejecutar código antes y después de la ejecución de un acción en determinado controlador.

Para crear un filtro de acción, se debe crear una clase que herede de ActionFilterAttribute, y sobrescribir las funciones OnActionExecuting (ejecutada antes de la acción del controlador) y/o OnActionExecuted (ejecutada una vez la acción del controlador ha finalizado).

Para mostrar su uso, la idea es crear un filtro que permita tener un log de  las ejecuciones de la ejecuciones de las acciones en PersonController, pero antes de crear el filtro crearemos una clase singleton que se encargará de hacer el log, asi que primero definimos una sencilla interfaz:

interface ILogWriter
{
	void Log(string message);
}

Luego la clase que implementa dicha interfaz:

public class LogWriter : ILogWriter
{
	private static readonly Lazy instance = new Lazy(() =&gt; new LogWriter());

	private LogWriter() { }

	public static LogWriter Instance
	{
		get
		{
			return instance.Value;
		}
	}

	public void Log(string message)
	{
		Debug.WriteLine(message);
	}
}

Ahora que ya tenemos lista la clase, creamos una clase llamada LogFilterAttribute la cual debe heredar de ActionFilterAttribute y sobrescribimos los métodos nombrados anteriormente:

public class LogFilterAttribute : ActionFilterAttribute
{
	public override void OnActionExecuting(System.Web.Http.Controllers.HttpActionContext actionContext)
	{
		//Get info using actionContext
		LogWriter.Instance.Log(&quot;Executed before at: &quot; + System.DateTime.Now);
	}

	public override void OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
	{
		//Get info using actionContext
		LogWriter.Instance.Log(&quot;Executed after at: &quot; + System.DateTime.Now);
	}
}

En este caso solo enviamos una simple cadena de texto, pero es posible obtener información del request utilizando el objeto actionContext.

Por último, para que el filtro creado funcione, lo que hacemos es decorar el controlador Person con el atributo creado:

[LogFilter]
public class PersonController : ApiController
{
	...
}

Espero el post les sea de utilidad, nos vemos en el siguiente artículo de Web API!

Saludos!

Descarga el ejemplo!

[ASP.NET Web API] Web API IV – Implementando Knockoutjs

Hola a todos, en el post anterior vimos como podemos consumir nuestro servicio REST de Web API utilizando jQuery y AJAX (míralo acá), creamos un archivo JavaScript para mantener separado el contenido (HTML) del comportamiento de la página (JavaScript), sin embargo, con solo observar el archivo js creado, nos damos cuenta que dicha afirmación no es del todo cierta, puesto que tenemos una dependencia total a los elementos del DOM, y si en algún momento el HTML llega a cambiar o los id´s de los elementos vamos a tener problemas.

Para solucionar el problema anterior, una posible solución es implementar un framework JavaScript como Knockout, el cual permite trabajar el patrón MVVM (model-view-view model) en el cliente; en este post no voy a entrar en detalles técnicos de este framework (probablemente luego haga una serie sobre el tema) ni a discutir si es o no la mejor opción, solo comentare que a mi me gusta, me ayuda a trabajar mejor en el cliente y que cumple su objetivo, además si hasta inicias con JavaScript, Knockout te será sencillo de entender.

Luego de una pequeña introducción iniciemos (seguimos con el ejemplo del anterior post), lo primero es añadir Knockout, para ello vamos a hacer uso de Nuget:

knockout

Ahora en la clase BundleConfig (en la carpeta App_Start) en el método RegisterBundles añadimos un nuevo bundle para knockout:

bundles.Add(new ScriptBundle(&quot;~/bundles/knockout&quot;).Include(
        &quot;~/Scripts/knockout-{version}.js&quot;));

Luego en el layout (Views/Shared/_Layout.cshtml) del sitio lo referenciamos al final:

@Scripts.Render(&quot;~/bundles/knockout&quot;)

Ahora que ya tenemos listo a Knockout, iniciamos con el refactoring de person.js, la idea es crear un ViewModel que permita trabajar de manera desconectada del DOM las operaciones CRUD implementadas, lo primero que haremos y para poder trabajar mejor con Knockout es agregar una referencia a knockout-2.3.0.debug.js (en el momento de escribir el post la versión que uso es la 2.3.0) en person.js para tener intellisense

/// &lt;reference path=&quot;../knockout-2.3.0.debug.js&quot; /&gt;

Luego definimos el modelo:

var PersonViewModel = function () {
    self = this;
    self.id = ko.observable();
    self.name= ko.observable();
    self.lastname= ko.observable();
    self.twitter= ko.observable();
    self.personList= ko.observableArray();
	.....
}

Y al definir el modelo ya tenemos varios cambios importantes:

  • Definición del objeto PersonViewModel
  • A self le asignamos this para evitar conflictos al acceder a las propiedades del objeto
  • Las propiedades se definen como observables, es decir si cambia la propiedad el objeto HTML asociado también lo hará, y viceversa.
  • La propiedad personList es observable y a la vez es un array.

Ahora comenzamos a añadir funciones a nuestro viewmodel:

Obtener todos los elementos

self.getAll = function () {
	$.getJSON('/api/person', function (data) {
		self.personList(data);
	});
}

En este caso de nuevo se realiza la petición con $.getJSON, la diferencia radica en que la respuesta se la seteamos como valor al array observable.

Obtener un elemento

self.getPersonById= function () {
	var url = '/api/person/' + self.id();
	$.getJSON(url)
		.done(function (data) {
			self.name(data.Name);
			self.lastname(data.LastName);
			self.twitter(data.Twitter);
		})
		.fail(function (erro) {
			self.clearForm();
	});
},

La funcionalidad básica permanece casi que igual, sin embargo los cambios que se observan son:

  • Se utiliza self.id() para obtener el valor de la propiedad id del objeto en lugar de consultar el DOM
  • Si la respuesta es correcta, se asignan los valores a las propiedades del objeto y no directamente a los elementos del DOM.

Eliminar elemento por id

self.deletePersonById= function () {
	var url = '/api/person/' + self.id();
	$.ajax({
		url: url,
		type: 'DELETE',
		contentType: &quot;application/json;chartset=utf-8&quot;,
		statusCode: {
			200: function () {
				self.getAll();
				alert('Person with id= ' + self.id() + ' was deleted');
				self.clearForm();
			},
			404: function () {
				alert('Person with id= ' + self.id() + ' was not found');
			}
		}
	});
},

El cambio importante es que para acceder al id de la persona de utiliza self.id() en lugar de acceder al elemento del DOM para leer su valor.

Actualizar y crear un elemento

self.updatePerson= function () {
	var url = '/api/person/' + self.id();
	$.ajax({
		url: url,
		type: 'PUT',
		data: ko.toJSON(self),
		contentType: &quot;application/json;chartset=utf-8&quot;,
		statusCode: {
			200: function () {
				self.getAll();
				alert('Person with id= ' + self.id() + ' was updated');
				self.clearForm();
			},
			404: function () {
				alert('Person with id= ' + self.id() + ' was not found');
				self.clearForm();
			},
			400: function () {
				self.clearForm();
				alert('Error');
			}
		}
	});
},

self.createPerson= function () {
	var url = '/api/person/';
	$.ajax({
		url: url,
		type: 'POST',
		data: ko.toJSON(self),
		contentType: &quot;application/json;chartset=utf-8&quot;,
		statusCode: {
			201: function () {
				self.getAll();
				self.clearForm();
				alert('Person was created');
			},
			400: function () {
				self.clearForm();
				alert('Error');
			}
		}
	});
},

En la actualización y creación de un elemento se comparten los cambios (por eso no lo separe acá), las dos acciones en el lado del servidor reciben un objeto de tipo Person, lo cual en el post anterior hacíamos creando un nuevo objeto, asignándoles propiedades y finalmente serializándolo, sin embargo Knockout ofrece una forma más sencilla de realizar este proceso, simplemente con ko.toJSON(modelo) se realiza la serialización del objeto (cool no?).

Bueno, lo anterior todo muy bonito… pero… y como relacionamos ese modelo con nuestro HTML dicho proceso tiene dos pasos:

Paso 1: Llamar el viewmodel y enlazarlo

En este caso, una vez la página este cargada, creamos un nuevo objeto de tipo PersonViewModel, luego con ko.applyBindings(modelo) aplicamos los bindgins y finalmente hacemos el llamado a la función que obtiene todos los elementos:

$(document).on(&quot;ready&quot;, function () {
    var personvm = new PersonViewModel();
    ko.applyBindings(personvm);
    personvm.getAll();
})

Paso 2: Definir los bindings en el HTML

Llego el momento de modificar nuestra vista, el nuevo código es:

&lt;div class=&quot;hero-unit&quot;&gt;
    &lt;h2&gt;Get All&lt;/h2&gt;
    &lt;div&gt;
        &lt;table id=&quot;tblList&quot; class=&quot;table table-bordered table-hover&quot;&gt;
            &lt;thead&gt;
                &lt;tr&gt;
                    &lt;th&gt;Name&lt;/th&gt;
                    &lt;th&gt;Last Name&lt;/th&gt;
                    &lt;th&gt;Twitter&lt;/th&gt;
                &lt;/tr&gt;
            &lt;/thead&gt;
            &lt;tbody data-bind=&quot;foreach: personList&quot;&gt;
                &lt;tr&gt;
                    &lt;td data-bind=&quot;text: Name&quot;&gt;&lt;/td&gt;
                    &lt;td data-bind=&quot;text: LastName&quot;&gt;&lt;/td&gt;
                    &lt;td data-bind=&quot;text: Twitter&quot;&gt;&lt;/td&gt;
                &lt;/tr&gt;
            &lt;/tbody&gt;
        &lt;/table&gt;
    &lt;/div&gt;
    &lt;h2&gt;Get one&lt;/h2&gt;
    &lt;div&gt;
        &lt;ul&gt;
            &lt;li&gt;
                &lt;label&gt;Id:&lt;/label&gt;
                &lt;input type=&quot;text&quot; id=&quot;txtIdSearch&quot; data-bind=&quot;value:id&quot; /&gt;
                &lt;input type=&quot;button&quot; id=&quot;btnSearch&quot; value=&quot;Search&quot; data-bind=&quot;click:getPersonById&quot; /&gt;
            &lt;/li&gt;
            &lt;li&gt;
                &lt;label&gt;Name:&lt;/label&gt;
                &lt;input type=&quot;text&quot; id=&quot;txtName&quot; data-bind=&quot;value:name&quot; /&gt;
            &lt;/li&gt;
            &lt;li&gt;
                &lt;label&gt;Last name:&lt;/label&gt;
                &lt;input type=&quot;text&quot; id=&quot;txtLastName&quot; data-bind=&quot;value:lastname&quot; /&gt;
            &lt;/li&gt;
            &lt;li&gt;
                &lt;label&gt;Twitter:&lt;/label&gt;
                &lt;input type=&quot;text&quot; id=&quot;txtTwitter&quot; data-bind=&quot;value:twitter&quot; /&gt;
            &lt;/li&gt;
            &lt;li&gt;
                &lt;input type=&quot;button&quot; id=&quot;btnCreate&quot; value=&quot;Create&quot; data-bind=&quot;click:createPerson&quot; /&gt;
                &lt;input type=&quot;button&quot; id=&quot;btnDelete&quot; value=&quot;Delete&quot; data-bind=&quot;click:deletePersonById&quot; /&gt;
                &lt;input type=&quot;button&quot; id=&quot;btnUpdate&quot; value=&quot;Update&quot; data-bind=&quot;click:updatePerson&quot; /&gt;
            &lt;/li&gt;
        &lt;/ul&gt;
    &lt;/div&gt;
&lt;/div&gt;
@section scripts
{
    &lt;script type=&quot;text/javascript&quot; src=&quot;@Url.Content(&quot;/Scripts/app/person.js&quot;)&quot;&gt;&lt;/script&gt;
}

El primer cambio se da en la definición del cuerpo de la tabla, en este caso haciendo uso de la propiedad data-bind le estamos asignamos la propiedad personList, y como usamos la función foreach entonces Knockout itera sobre cada elemento del array, luego en cada elemento td usando nuevamente la propiedad data-bind a la propiedad text le relacionamos la propiedad de la cual va a mostrar su valor.

Para los input, en el data-bind a la propiedad value le asignamos alguna de las propiedades del ViewModel, para los botones igualmente con data-bind al evento click le relacionamos una función del ViewModel.

El cambio más importante en esta sencilla implementación de Knockout, es que si revisamos de nuevo el archivo person.js NO se tiene ninguna dependencia ni referencia al DOM, lo cual ofrece una mejor estructura de nuestra aplicación y la puede hacer más mantenible y extensible.

Espero el post les haya gustado, y esperen la siguiente entrega de este serie sobre Web API!

Saludos!

Descarga el ejemplo!

1 2 3 10