[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

[Azure] Azure Web Sites – Escalamiento

Posted on Actualizado enn

Hola, en el post anterior hablamos de cómo podemos integrar un Azure Web Site con un repositorio, para así automatizar el proceso de despliegues y tener la posibilidad de realizar rollbacks en cualquier momento; hoy vamos a ver como es posible escalar dicho Web Site, bastante útil cuando ya lo que viene por default no es suficiente.

Para comenzar a escalar el Web Site, seleccionamos la opción SCALE, por defecto nuestro Web Site corre en el modo FREE con 1 sola instancia:

escalamiento1

Bien, para este ejemplo vamos a escalar a STANDARD, y automáticamente tenemos nuevas opciones disponibles como:

  • Escoger Web Site: Permite seleccionar el Web Site.
  • Tamaño de instancia: Permite escoger entre Small, Medium y Large, lo cual se verá reflejado en el tamaño de la máquina virtual.
  • Número de instancias: Permite seleccionar el número de instancias asociadas al Web Site.
  • Escalamiento: Permite escalar el Web Site en una hora determinada, o por algún consumo de CPU específico.

escalamiento2

Ahora hagamos enfásis en la parte de escalamiento, si escogemos en la metrica que escale por CPU, dos opciones nuevas se habilitan, la cantidad de instancias y el consumo de CPU (rango de uso de CPU), allí entonces definimos el número de instancias (mínimo y máximo) cuando el consumo de CPU este en un rango determinado:

escalamiento3

La otra opción es configurar el escalamiento para una hora determinada, esto es bastante útil cuando conoces con anterioridad los picos de tráfico del Web Site, para ello damos click en Set up schedule times, y en el modal que se muestra configuramos el escalamiento, allí inicialmente podemos escoger entre escalamiento diferente para el día y la noche y/o para días entre semana y fines de semana, y luego establemos los horarios:

escalamiento4

Al confirmar ya tenemos disponible los escalamientos creados, solo resta decirle que número de instancias vamos a usar:

escalamiento5

Espero el post les sea interesante, hasta la próxima!

Saludos!

[Azure] Azure Web Sites – Integración con repositorios

Posted on Actualizado enn

Hola, ultimamente he visto varias personas que ven los Azure Web Sites como simples “hosting”, creyendo que para lo único que sirven es para publicar tu sitio Web y… listo, así que pienso hacer una pequeña serie de post para mostrar algunas características que permiten a los Azure Web Sites ser un componente robusto e interesante.

En este post vamos a revisar como es posible enlazar el Azure Web Site con algún tipo de respositorio (Visual Studio Online, Git Local, GitHub, Dropbox, Bitbucket, CodePlex o alguno externo) para automatizar los despliegues, en ese caso vamos a relacionarlo con un repositorio en GitHub, para ello vamos al dashboard del Web Site y seleccionamos Set up deployment from source control, luego se abre una ventana modal para elegir el tipo de repositorio, por lo que para este ejemplo escogemos GitHub:

repositorio

Luego nos pide autenticarnos con nuestra en GitHub, una vez confirmada la autenticación, escogemos el repositorio y el branch:

branch

Una vez finalizada la integración, Windows Azure se encarga de realizar el despliegue y nos informa del mismo:

info deploy

Uno de los puntos interesantes de esta integración, es que cada vez que se haga commit al repositorio el GitHub, Azure realizará el despliegue de los cambios y vamos a ver el historial de todos ellos:

historial despliegues

Si por alguna razón, necesitamos volver a un deploy anterior, lo podemos hacer sin problema, basta con seleccionar el deploy y en la parte inferior seleccionar Redeploy para hacer el rollback a una versión anterior:

redeploy

Espero les sea de utilidad, en próximos post seguiremos hablando de los Azure Web Sites!

Saludos!

[C#] Custom value resolver en AutoMapper

Posted on Actualizado enn

Hola, anteriormente hicimos una introducción a AutoMapper, vimos algunos conceptos básicos para rápidamente ponernos a tono con dicha herramienta y finalmente comente algunas características importantes y muy comúnmente utilizadas, y como podrán adivinar quedaron algunos temas por fuera, así que en esta oportunidad vamos a revisar una de ellas, los Value Resolver.

En esencia podemos crear un Value Resolver personalizado para especificar un mapeo diferente al por defecto (propiedad origen a propiedad destino) para cumplir con necesidades específicas, así que en esta oportunidad vamos a personalizar la asignación a la propiedad Name de la clase ClientViewModel. Así que vamos a cambiar un poco la clase ClientViewModel, donde eliminamos la propiedad LastName, así nuestra clase ahora solo tiene dos propiedades, Name y Email:

public class ClientViewModel
{
	public string Name { get; set; }

	public string Email { get; set; }
}

La concatenar las propiedades Name y LastName de la clase Cliente y ese valor será el asignado para el Name de ClientViewModel, así que vamos a crear un Value Resolver que nos ayude con esa tarea, crear un Value Resolver personalizado es tan simple como tener una clase que herede de ValueResolver y sobre-escribir el método ResolveCore. Así que creamos una clase llamada FullNameResolver que hereda de ValueResolver y definimos el source (la clase cliente original) y el tipo de la salida (un string en este caso), y en el override del método ResolveCore simplemente concatenamos las propiedades y retornamos el valor:

public class FullNameResolver : ValueResolver<Client, string>
{
	protected override string ResolveCore(Client source)
	{
		return string.Format("{0} {1}",source.Name, source.LastName);
	}
}

Ya que se ha creado el resolver, solo resta usarlo, así que vamos a nuestra clase CustomDto y allí en el método Configure en la definición del mapeo de la propiedad Name llamamos el resolver creado con la función ResolveUsing y le pasamos el FullNameResolver creado anteriormente:

protected override void Configure()
{
	Mapper.CreateMap<Client, ClientViewModel>()
		.ForMember(d => d.Name, o => o.ResolveUsing<FullNameResolver>())
		.ForMember(d => d.Email, o => o.MapFrom(c => c.Email));
}

Por último una prueba:

ValueResolver

Hasta la próxima, saludos!