Todo en ASP.NET

[C#] Microsoft Unity II – Iniciando con Unity

Posted on 05/07/2014 Actualizado enn 05/06/2014

Post de la serie:

• Microsoft Unity I – Introducción a la inyección de dependencias
• Microsoft Unity II – Iniciando con Unity

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:

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:

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!

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

Posted on 05/02/2014 Actualizado enn 05/07/2014

Post de la serie:

• Microsoft Unity I – Introducción a la inyección de dependencias
• Microsoft Unity II – Iniciando con Unity

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.