[C#] Microsoft Unity II – Iniciando con Unity

Posted on Actualizado enn

Post de la serie:

Hola, en el anterior post (dale una mirada acá) se habló sobre las ventajas y características de utilizar Inyección de Dependencias, sin embargo no vimos nada de código, por lo que hoy si vamos a tirar algunas lineas para ir mirando su funcionamiento.

En el post anterior comentaba que uno de los principios básico de la DI es trabajar contra abstracciones y no contra implementaciones, y en resumen podemos decir que vamos a trabajar contra interfaces y no contra clases, no voy a entrar en detalle sobre el cómo funcionan las interfaces (lo podemos tratar en otro post), así que solo vamos a ver un pequeño ejemplo en donde tenemos una clase que se encarga de guardar en un log (en los ejemplos voy a estar utilizando ASP.NET MVC, pero aplican a cualquier tipo de proyecto):

public class LogFile
{
	public void Log(string msg)
	{ 
		//TODO: Log the msg
	}
}
public class HomeController : Controller
{
	private readonly LogFile log;

	public HomeController()
	{
		log = new LogFile();
	}

	public ActionResult Index()
	{
		log.Log("Action: Index");
		return View();
	}
}

Revisando el código anterior, es claro que nuestro HomeController que no es más que una clase depende totalmente de la clase LogFile, en este caso se dice que tenemos un fuerte acoplamiento, ya que la clase HomeController conoce totalmente a LogFile, bueno pero vamos ahora a reescribir un poco el código para trabajar contra interfaces y tener un poco menos de acoplamiento; lo primero es crear una interfaz ILog para que sea implementada por la clase LogFile:

public interface ILog
{
	void Log(string msg);
}
public class LogFile : ILog
{
	public void Log(string msg)
	{ 
		//TODO: Log the msg
	}
}

Bueno, hasta el momento solo ha sido un pequeño cambio, ahora es momento de cambiar HomeController para trabajar contra la interfaz y no con la clase específica:

public class HomeController : Controller
{
	private readonly ILog log;

	public HomeController(ILog log)
	{
		this.log = log;
	}

	public ActionResult Index()
	{
		log.Log("Action: Index");
		return View();
	}
}

Si ahora revisamos HomeController, por ningún lado aparece la clase LogFile, y HomeController solo conoce la interfaz ILog, es decir solo tiene conocimiento de lo que hace más no de cómo lo hace, y otro punto importante, en el constructor de la clase le inyectamos la dependencia. Si en este punto probamos la aplicación vamos a obtener un error, y por el momento les dejo dos posibles soluciones Creando una factoría de controladores personalizada e Inyectando dependencias con Microsoft Unity.

Bueno pero hasta el momento nada de Unity…y es acá donde iniciamos a hablar de él. Unity es una herramienta que se conoce como un DI Container o un contenerdo de inyección de dependencias (existen muchos otros bastante buenos), y la idea básicamente es tener un sitio componente especializado en donde registremos todas las dependencias y como se van a resolver, además se va a encargar de manejar el tiempo de vida de cada componente registrado (lo trataremos en otro post de la serie) entre otros.

Ahora manos a la obra, lo primero es añadir la referencia a Unity mediante Nuget, en este caso buscamos por Unity y escogemos Unity bootstrapper for ASP.NET MVC:

unity II - img I

El paquete anterior añade un par de clases en el folder App_Start:

  • UnityConfig: Acá se van a registrar las dependencias.
  • UnityMvcActivator: Es llamada cuando se inicia la aplicación (ya que es del tipo WebActivator) y se encarga de crear el contenedor de Unity.

Luego de tener ya listo nuestro contenedor, el siguiente paso es comenzar a registrar nuestras dependencias, pero antes de hacerlo revisemos tres métodos (que hacen parte del ciclo de ejecución) claves en Unity:

  • RegisterType: Es utilizado para relacionar o definir el mapping entre la interfaz y el tipo concreto que se va a utilizar, la sintaxis básica es container.RegisterType<Interfaz,TipoConcreto>(); en otro post de la serie revisaremos las otras formas de registrar y crear los mappings.
  • Resolve: Es utilizado para obtener el tipo concreto de una interfaz, la sintaxis es: container.Resolve<Interfaz>();
  • Dispose: Se encarga de liberar recursos.

Ahora para registrar las dependencias, vamos a la clase UnityConfig, más exactamente en el método RegisterTypes y allí realizamos el registro de la dependencia, para el ejemplo solo será para la interfaz ILog, por el momento la clase debe verse algo así:

public class UnityConfig
{
	#region Unity Container
	private static Lazy<IUnityContainer> container = new Lazy<IUnityContainer>(() =>
	{
		var container = new UnityContainer();
		RegisterTypes(container);
		return container;
	});

	/// <summary>
	/// Gets the configured Unity container.
	/// </summary>
	public static IUnityContainer GetConfiguredContainer()
	{
		return container.Value;
	}
	#endregion

	/// <summary>Registers the type mappings with the Unity container.</summary>
	/// <param name="container">The unity container to configure.</param>
	/// <remarks>There is no need to register concrete types such as controllers or API controllers (unless you want to 
	/// change the defaults), as Unity allows resolving a concrete type even if it was not previously registered.</remarks>
	public static void RegisterTypes(IUnityContainer container)
	{
		// NOTE: To load from web.config uncomment the line below. Make sure to add a Microsoft.Practices.Unity.Configuration to the using statements.
		// container.LoadConfiguration();

		// TODO: Register your types here
		container.RegisterType<ILog, LogFile>();
	}
}

Ahora si podemos ejecutar la aplicación, y en este caso podemos ver que la dependencia se resuelve correctamente:

unity II - img II

Espero les haya gustado el post, en el siguente post ya vamos a entrar más en detalle en otras características de Unity!

Y no te olvides compartir el post!

Promoción en Packt Publishing

Posted on

Hola, y de nuevo los amigos de Packt Publishing nos comparten una excelente promoción, en esta ocasión todo su contenido por tan solo 10 dolaritos, ojo que es sólo el 6 de Mayo  así que no se lo pierdan!🙂

DRM-Landing-Page-Banner

Saludos!

[C#] Microsoft Unity I – Introducción a la inyección de dependencias

Posted on Actualizado enn

Post de la serie:

Hola, inicio una serie de post sobre la inyección de dependencias, la inyección de dependencias conocida por las siglas DI por su nombre en inglés Dependency Inyection, es un patrón de diseño altamente utilizado en aplicaciones medianas/grandes que requieren un ciclo de vida especial durante todo su proceso de desarrollo y mantenimiento, en este primer post no vamos a ver código (al menos no mucho), ya que quiero hablar del por qué DI es importante y que beneficios obtenemos al utilizarla.

Durante el proceso de desarrollo de software y espero que no sea tu caso (a mi si que me ha pasado) es posible que algunos requerimientos cambien o bien que se añadan nuevos, esto puede ser dado no solo por el cliente, dichos cambios pueden venir de negocio, o de la misma área de tecnología… sin importar el origen del cambio, lo importante es que nuestro sistema este preparado para asumir esos cambios y no se genere un impacto muy fuerte en el proyecto, claro que también depende del tipo del requerimiento, pero en general esa es la idea.

Para que nuestro sistema este preparado para asumir cambios (entre otras cosas) es importante tener una arquitectura extensible y modular que permita ser ágiles en el momento de responder a nuevas necesidades/requerimientos que vayan llegando, y es allí donde la inyección de dependencias juega un papel importante.

La inyección de dependencias ofrece algunos beneficios como:

  • Mantenibilidad: Cuando el sistema comienza a crecer tanto en tamaño como en funcionalidad, se va complicando el modificar/arreglar alguna funcionalidad, ya que cualquier cambio puede afectar múltiples partes del sistema o bien ser necesario realizar el mismo cambio en diferentes partes (si, creo que te has dado que has estado repitiendo código) con lo cual es engorroso realizar estos cambios y el sistema es muy sensible a introducir nuevos bugs; con la inyección de dependencias y un diseño adecuado del sistema las tareas de mantenimiento se vuelven más sencillas y es menos probable que se inyecten nuevos bugs o que haga falta replicar el cambio en alguna parte del código, ya que se tiene claro que componente hace que cosa, y aquí encontramos un principio clave de la DI, trabaja contra abstracciones y no contra implementaciones, y que quiere decir esto? Básicamente que debes trabajar contra interfaces (la abstracción) y no con la clase concreta (la implementación) así tu sistema va a funcionar con cualquier clase que implemente la interfaz que requieres.
  • Testeabilidad: Uno de los puntos en mi opinión más importante del usar DI, es su facilidad para testear componentes del sistema, y esto va muy de la mano con TDD (Test Driven Development), en donde la idea es poder tener un set de pruebas unitarias para probar/validar la funcionalidad de nuestro sistema, así al hacer algún cambio en el desarrollo, es posible identificar tempranamente si se inyecto algún bug en el sistema gracias al todo el conjunto de pruebas unitarias que al menos deberían validar el core y/o partes principales del sistema. Este tema de pruebas y sobre todo de TDD es bastante amplio e interesante, así que te recomiendo le des una buena revisada.
  • Extensibilidad: Siempre va a ser necesario seguir añadiendo funcionalidad a una aplicación, y gracias a la abstración sobre los componentes específicos sería posible por ejemplo cambiar de un caché local a implementar un cache de segundo nivel con AppFabric o un Memcached.
  • Poco acoplamiento: Otro punto bastante interesante, la idea de tener poco acoplamiento entre componentes permita facilmente cambiar la implementación de uno de ellos o reemplazarlo por otro, adicionalmente ayuda en la testeabilidad de los mismos, ya que al ser poco dependientes de otros sistemas/elementos podemos realizar pruebas sobre ellos de una manera relativamente sencilla.
  • Desarrollo en equipo: Cuando el equipo de desarrollo comienza a crecer, es cada vez más importante distribuir requerimientos a cada miembro del equipo de desarrollo, y gracias a que se tienen componentes desacoplados, es sencillo dividir al equipo para que cada miembro se enfoque en una parte específica del sistema, además, si recordamos la idea de trabaja contra abstracciones y no contra implementaciones, cada componente del sistema va a conocer que hace el otro (por medio de un contrato, es decir la interfaz) pero no le interesa como lo haga.

Luego de conocer algunos de los beneficios de implementar inyección de dependencias, es momento de hablar el cómo podemos usarla. Existen tres formas en las cuales podemos inyectar una dependencia:

  • Inyección por método
  • Inyección por constructor
  • Inyección por propiedades

Espero esta pequeña introducción les sea tanto útil como interesante, nos vemos en el siguiente post donde ya vamos a comenzar a hablar y utilizar Microsof Unity.

Y no te olvides compartir el post!

Saludos.

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

Posted on Actualizado enn

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

Posted on Actualizado enn

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!

Promoción de ebooks en Packt Publishing

Posted on

Hola amigos, quiero compartir con todos ustedes uan excelente promoción que los amigos de Packt Publishing tienen, consiste en que compras un ebook y te regalan otro, aprovecha está excelente promoción para seguir aprendiendo🙂

2000th-Book-Home-Page-Banner

Recuerda el link es: http://bit.ly/1j26nPN

Saludos!

[Azure] Azure Web Sites – Backups

Posted on Actualizado enn

Hola, siguiente con la seria de post sobre Azure Web Sites, hoy vamos a revisar la características de Backups, como primera medida, para poder hacer uso de dicha característica el Web Site debe estar establecido en modo Standard, asi que una vez vamos a la opción de Bakups tenemos dos opciones, backups a demanda y backups automáticos; para los dos tipos de backups es necesario utilizar una cuenta de storage:

backups1

Backup por demanda

Generar el backup por demanda es tan sencillo como dar click en la opción de backup:

backups2

Y Windows Azure inicia dicho proceso:

backups3

Y listo!

Backups Automáticos

La otra opción es configurar los backups para que se generen de forma automática, para ello habilitamos la característica en Automated Backup, luego establecemos la frecuencia (por el momento solo se puede en días) y la fecha de inicio de los bakups:

backups4

Finalmente, podemos realizar una restauración del sitio desde algunos de esos backups, para ellos en la parte inferior seleccionamos Restore Now:

backups5

Luego seleccionamos el backup que deseamos restaurar:

backups6

Y finalmente podemos escoger si restaurar en un nuevo sitio Web o en el mismo sitio:

backups7

Y listo, espero les haya sido de utilidad el post!

@julitogtu