Usando el mismo ejemplo de la aplicación “Saludador” (Iniciada en el Lanzamiento de VisualStudio 2010 en Tijuana) en el siguiente video muestro otras opciones al momento de importar partes de nuestro objeto usando MEF. En concreto ImportingConstructor y AllowDefault.
Entradas Relacionadas:
Introducción a MEF Parte 1
Introducción a MEF Parte 2
Introducción a MEF Parte 3 - Recomposición
Continuando con la aplicación de ejemplo sobre MEF, en esta ocasión muestro el concepto de recomposición de MEF. El cual permite cargar componentes de forma dinámica mientras nuestra aplicación corre.
Algo a notar con este ejemplo fue que lo realice utilizando la librería de MEF que se encuentra en codeplex, usando VisualStudio 2008 con el .Net Framework 3.5. En lugar de utilizar VS2010 con el .Net 4.0 como lo había venido haciendo. Por ahora el código es el mismo para ambas versiones del framework.
Como siempre mi meta es que estos videos (screencasts) no pasen de 5 min, por lo tanto si fui muy rápido, me falto algo o me equivoque, les agradeceré sus comentarios.
También se puede ver el video desde screencast.com
Post Relacionados:
Introducción a MEF Parte 1
Introducción a MEF Parte 2
Una de las ventajas sobre la plataforma ASP.NET MVC sobre WebForms es que podemos utilizar el principio de inversión de control usando la inyección de dependencias (generalmente a través de los constructores). De tal forma que nuestros controladores reciben parámetros en los constructores. Esto hace que la plataforma MVC no pueda, por si sola (usando el DefaultControllerFactory), construir nuestros controladores usando el constructor que recibe parámetros. Es por ello que vemos ejemplos (como el proyecto plantilla de VisualStudio) donde se sobre carga el constructor con uno que no recibe parámetros y es el propio controlador el encargado de crear sus dependencias. Lo cual va en contra del principio de inversión de control.
Resolver este problema es muy sencillo, basta con crear nuestro propio IControllerFactory que es el contrato que utiliza la plataforma MVC para construir los controladores. En este ejemplo nuestro controller factory hará uso de Unity un Contenedor de dependencias (IoC container) para administrar las dependencias.
La forma mas sencilla de crear un IControllerFactory es heredar del DefaultControllerFactory y redefinir el método GetControllerInstance. Aquí muestro el código:
public class UnityControllerFactory: DefaultControllerFactory
{
readonly IUnityContainer container;
public UnityControllerFactory(IUnityContainer container)
{
this.container = container;
}
protected override IController GetControllerInstance(
RequestContext requestContext, Type controllerType)
{
if (controllerType == null )
return null;
return (IController)container.Resolve(controllerType);
}
}
Como puede verse el UnityControllerFactory recibe un contenedor con las dependencias registradas, el cual utiliza para crear los controladores en el método GetControllerInstance. No hace falta registrar los controladores en el contenedor ya que Unity puede construir instancias de tipos no registrados.
Una vez creado nuestro controller factory es necesario indicarle a MVC (en concreto al ControllerBuilder) que utilice nuestro UnityControllerFactory para crear los controladores; el código queda algo así:
var container = new UnityContainer();
//aqui se registran las dependencias
ControllerBuilder.Current.SetControllerFactory(
new UnityControllerFactory(container));
Esto se debe ejecutar al iniciar la aplicación (el Application_Start() en el Global.asax.cs).
Como puede verse con muy poco código podemos estar usando un IoC container en nuestra aplicación ASP.NET MVC, no es complicado y el UnityControllerFactory puede reutilizarse en otras aplicaciones MVC. Así que, ya lo saben, no hay pretexto para no utilizar un contenedor de dependencias.
Hay ocasiones en las que necesitamos tener un objeto compartido por varios objetos en nuestra aplicacion web, similar al patrón singleton, pero solo para esa petición HTTP. Es decir sin compartirlo en toda la aplicación.
Hace tiempo escribí sobre como compartir un LinqToSql DataContext por cada request en una aplicación web. Ahora utilizando Unity podemos lograr ese comportamiento y dejar que el contenedor de dependencias se encargue de darnos la instancia adecuada.
Para manejar el tiempo de vida de las instancias unity utiliza lo que llama LifetimeManager, entonces lo primero que debemos hacer es crear nuestro LifetimeManager, en este caso lo llamaré HttpRequestLifetimeManager y heredamos de la clase abstracta Microsoft.Practices.Unity.LifetimeManager y debemos de definir 3 metodos GetValue, RemoveValue y SetValue.
public class HttpRequestLifetimeManager: LifetimeManager
{
object key;
public HttpRequestLifetimeManager(): this(null)
{
}
public HttpRequestLifetimeManager(object key)
{
this.key = key;
}
public override object GetValue()
{
if (key == null) return null;
return HttpContext.Current.Items[key];
}
public override void RemoveValue()
{
}
public override void SetValue(object newValue)
{
if (key == null)
key = newValue.GetType();
HttpContext.Current.Items[key] = newValue;
}
}
Lo que hace el HttpRequestLifetimeManager es guardar la instancia de la clase en el Items dictionary con el key que se le especifique en el constructor, si no se ha especificado un key, entonces utilizará el tipo del objeto para identificarlo en el diccionario.
Una vez teniendo nuestro LifetimeManager solo es cuestión de especificarle a unitity, al momento de registrar nuestro tipo, que utilice nuestro HttpRequestLifetimeManager para manejar el tiempo de vida de nuestra instancia.
Por ejemplo supongamos que tenemos declarados algunas clases (posiblemente repositorios) que recibe el constructor un DataContext algo como esto:
public class UserRepository : IUserRepository
{
readonly MyDataContext db;
public UserRepository(MyDataContext db)
{
this.db = db;
}
...
Si queremos que todos nuestros repositorios compartan el mismo MyDataContext por cada request, entonces configuramos nuestro contenedor (generalmente en el Global.asx.cs) de la siguiente manera:
var container = new UnityContainer();
container.RegisterType<IAccountRepository, AccountRepository>();
container.RegisterType<IUserRepository, UserRepository>();
container.RegisterType<MyDataContext>(
new HttpRequestLifetimeManager(), new InjectionConstructor());
Ahí podemos ver como al registrar MyDataContext paso una instancia de la clase HttpRequestLifetimeManager para usar la misma instancia durante todo el request y además le paso un instancia de InjectionConstructor para indicarle que utilice el constructor sin argumentos de nuestra clase MyDataContext.
Una vez hecho esto nuestro contenedor se encargará de entregarnos repositorios que comparten el mismo datacontext por cada request.
Siguiendo con el ejemplo del post anterior sobre MEF (La aplicación para consola “Saludador” que presente en el Launch de Visual Studio 2010 en Tijuana). En este screencast muestro como usar MEF para que alguien que no tiene acceso al código fuente de la aplicación, pueda extenderla (plugins) y agregar sus propios saludos.
Debido a que los videos solo los quiero realizar de 5 min, tuve que irme (quizás) un poco rápido. Como siempre cualquier comentario es bienvenido.
Post relacionado: Introducción a MEF Parte 1
Código Fuente:En el pasado Launch de Visual Studio 2010 en Tijuana presenté el tema: Extendiendo Aplicaciones con MEF. Debido a que olvide grabar la presentación, quise rehacer el ejemplo dividiéndolo en screencasts de no mas 5 min. Usando el mismo ejemplo que en la sesión. Espero sirva como introducción para quienes quieran conocer sobre MEF (Managed Extensibility Framework).
El ejemplo trata de una aplicación para consola que tiene una lista de saludos, el usuario puede seleccionar el saludo que guste y ejecutarlo. La idea es que el saludador pueda ser extendido, de tal forma que yo (como desarrollador de la aplicación) o cualquier tercero pueda agregar saludos a la aplicación.
En este primer video, muestro el funcionamiento básico de MEF (Importar, Exportar y Componer).
Post Relacionado: Introducción a MEF Parte 2
En la pasada reunión de la comunidad TJ.Net presenté el tema IoC, donde mostré un ejemplo usando el contenedor de dependencias Unity. Una de las preguntas de los asistentes fue sobre si unity siempre crea nuevas instancias para los tipos registrados y como podría indicarle que utilice siempre la misma (lo que se conoce como el patrón singleton). Al momento de la reunión conteste que por omisión Unity crea una nueva instancia cada que resuelve un tipo, pero que sí era posible indicar un comportamiento distinto, sin embargo no recordé la manera exacta para ello. Bueno pues aquí la respuesta.
Al registrar un tipo con el método registerType<TFrom, TTo> podemos pasarle un LifetimeManager el cual será encargado de manejar el tiempo de vida de las instancias resueltas por el contenedor. Podríamos crear nuestro propio LifetimeManager, pero (para el caso del patrón singleton) unity ya cuenta con uno del tipo ContainerControlledLifetimeManager.
Así que lo único que necesitamos para que nuestro contenedor implemente el patrón singleton al momento de resolver nuestro tipo es pasarle una instancia de la clase ContainerControlledLifetimeManager. Utilizando el mismo ejemplo de la reunión, podríamos suponer que necesitamos que nuestro INotificationService sea siempre la misma instancia para todos los componentes que requieran usarlo. Entonces el código donde registramos nuestro tipo quedaría así:
container.RegisterType<INotificationService, NotificationServiceWithTemplates>(Con esto logramos el patrón singleton con unity.
new ContainerControlledLifetimeManager());
El día de ayer (Miércoles 24 de Marzo 2010) fue la Reunión 33 de la comunidad TJ.NET donde presenté el tema “Inversión de control (IoC)”. La reunión se llevo a cabo en las instalaciones del Instituto Tecnológico de Tijuana.
En la reunión presenté una introducción a lo que se refiere el principio IoC; con ejemplos como: el usar eventos en nuestros componentes para la interfaz de usuario y el utilizar un Contenedor de dependencias (IoC Container) para realizar una Inversión de control aplicando el patrón de diseño “Inyección de dependencias”. Como ejemplo se refactorizó una aplicación Web ASP.NET para usar un IoC Container (Unity en este caso). La presentación que fue grabada y el material (diapositivas y archivos) pueden ser descargados desde la página del evento en la comunidad.
En el post anterior mostré como iniciar con mongoDB utilizando las herramientas que obtenemos al descargar la base de datos. Ahora quiero mostrar las mismas operaciones pero desde .Net (específicamente C#). Para esto es necesario descargar el driver para hablar con mongo desde .net
Para abrir la conexión a la base de datos debo crear una instancia de la clase MongoDB.Driver.Mongo, llamar el método Connect y después hacer un getDB con el nombre de la base de datos a la que quiero conectarme. Tomando el ejemplo anterior de la libreta de direcciones, el código queda así:
var mongo = new Mongo();
mongo.Connect();
var db = mongo.getDB("AddressBook");
una vez conectado a la base de datos obtengo una referencia a mi colección de documentos llamada “Contacts” (similar al concepto de tabla en una base de datos relacional).
var contacts = db.GetCollection("Contacts");
Ahora para insertar documentos creamos instancias de la clase MongoDB.Driver.Document (el cual es básicamente un diccionario de datos), le damos valores y lo insertamos a nuestra colección de contactos; como en el post anterior inserto 2 documentos a nuestra colección:
var mario = new Document();
mario["Name"] = "Mario";
mario["Phone"] = "1234567";
contacts.Insert(mario);
contacts.Insert(new Document()
.Append("Name", "Humberto")
.Append("Phone", "5555555")
);
Puede observarse dos formas de crear documentos. Una vez teniendo dos contactos (Mario y Humberto). Voy a actualizar al contacto con el nombre “Mario”. Aprovechando que estoy usando una base de datos no relacional, cambiaré las campos del documento, para ello utilizo el método Update de la colección contacts pasando como primer parámetro el nuevo documento y como segundo parámetro un documento que me sirve como selector
contacts.Update(
new Document()
.Append("FirstName", "Mario")
.Append("LastName", "Cornejo")
.Append("Phone", "1234567")
, new Document()
.Append("Name", "Mario")
);
Para hacer solo la actualización del campo teléfono del contacto con el nombre “Humberto” puedo hacer lo siguiente:
var humberto = contacts.FindOne(new Document().Append("Name", "Humberto"));Aquí utilice el mismo método Update, pero solo le pase como parámetro el documento actualizado. Como se puede ver, la forma de realizar las operaciones desde C# es muy similar a como lo haríamos desde la consola usando la aplicación Mongo.exe
humberto["Phone"] = "4444444";
contacts.Update(humberto);
Recientemente he empezado a jugar con la base de datos no relacional MongoDB, grabe un mini-screencast donde muestro la características básicas de esta base de datos orientada a documentos.
También puedes ver el video directamente desde www.screencast.com
public interface IDataContextFactory<T> where T: DataContext, new() { T GetCurrentDataContext(); void DisposeCurrentDataContext(); }
public class WebDataContextFactory<T>: IDataContextFactory<T> where T : DataContext, new() { public T GetCurrentDataContext() { var dataContext = HttpContext.Current.Items[typeof(T)] as T; if (dataContext == null) { dataContext = new T(); HttpContext.Current.Items[typeof(T)] = dataContext; } return dataContext; } public void DisposeCurrentDataContext() { var dataContext = HttpContext.Current.Items[typeof(T)] as T; if (dataContext != null) dataContext.Dispose(); } }
En el post anterior (screencast) mostré como escribir las pruebas para un validador que usa la librería FluentValidation, debido a que se me acababan los 5 minutos, solo mostré las pruebas. en esta ocasión muestro como escribir el código para satisfacer dichas pruebas, el cual es muy simple. el screencast dura solo 2 minutos
En este mini-screencast (5 min) muestro como escribir las pruebas unitarias para un validador que será escrito utilizando la librearía FluentValidation
