Amigos, ya tenemos el sitio oficial de la comunidad, funcionando y llenandose. Tenemos: blogs(del buró del speakers de la comunidad; Marlon Ramos, Cristian Prieto, Carlos Lone y tu servidor y habrán otros mas.), noticias, forums, fotos, downloads, articulos.
Que esperas para enterarte de lo ultimo en desarrollo y tecnologia .NET. Integrate lo antes posible y asiste a nuestras reuniones quincenales en el hotel Intercontinental en Guatemala, los miercoles a las 18:30 p.m.
Esta es la dirrección: http://guatecommunity.net
Saludos,
Manolo Herrera
Cooodinador de la comunidad de desarrolladores .NET en Guatemala
MVP Client Application 2007
viernes, 22 de febrero de 2008
Dependency Injection
Al parecer este patrón de diseño DI resuelve el problema de acoplamiento que sufren las aplicaciones que impiden la extensibilidad, mantenibilidad y la prueba (o testing ) y esta muy de moda. Es el patrón que nos llevará a otro nivel en las aplicaciones desacopladas, permitiendo la extensibilidad que se traducirá en productividad y alta calidad del software, algo que hemos esperado por años y que hoy en día esta madurando y convirtiéndose en una realidad en la industria de software y en la comunidad de desarrolladores en todo el mundo.
Esto no es nuevo, y viene del mundo java (su mayor expositor el chief scientiest y gurú de los patrones de diseño Martin Fowler http://www.martinfowler.com ), pero Microsoft ha hecho para la comunidad de usuarios de desarrollo de la plataforma .NET una solución muy elegante. Y fue estrenada con las Software Factories, en especial la Web Client Software Factory, que a través de un agente llamado Object Builder de las Microsoft Enterprise Library 3.1 inyecta de manera elegante por medio de atributos que encuentra en las diferentes implementaciones dentro de las WCSF los servicios o componentes dependientes de la clase a crear en memoria. Esto tampoco quiere decir que Microsoft hasta ahora lo esta implementando o lo conoce. Hay artículos del 2005 que hablan ya de esta práctica en la aplicación de este patrón.
Es importante mencionar que el DI no es el único patrón de diseño que soluciona el problema de aplicaciones fuertemente acopladas esta el observer pattern entre otros, que también se utiliza para desacoplar segmentos de código que estaban fuertemente acoplados. Lo interesante de DI es que resuelve un sin número de problemas con distintas implementaciones. También cabe mencionar que Microsoft no es el único que ha hecho una implementación de el patrón DI entre ellos están Casttle Project http://www.castleproject.org/ y Spring Net http://www.springframework.net/ . No obstante la gente de Patterns&Practices ha visto tanto interes en ello que ha creado un nuevo proyecto llamado Unity el cual ahislo de la composite web application block el framework de DI (para los intresados en el proyecto: http://www.codeplex.com/unity ).
Es importante mencionar desde el punto de vista de diseño de patrones que el DI cumple creo yo con dos importantes principios de diseño y son los siguientes:
Favor Composition over inheritance and
Strive for loosely coupled designs between objects that interact.
El primero muchas veces la solución se encuentra en la colaboración de clases a través de interfaces y en la descomposición de una clase en varias y no en la herencia misma que tiene sus pro y contra de esto los patrones de diseño para mas información el libro de Head First Design Patterns es una guía completa de patrones de diseño y un excelente libro para comprenderlos.
El segundo principio que muchos patrones de diseño cumplen se base en las siguientes premisas:
La única cosa que sabe la clase consumidora acerca de la clase proveedora del servicio es que implementa a un contrato o interfase.
No es necesario modificar la clase consumidora si cambiamos o implementamos nuevas funcionalidades en la clase proveedora del servicio o lo único que se mantiene intacto es el contrato que se definió para colaborar entre ellas.
Se puede utilizar independientemente tanto la clase consumidora como el cliente porque no están fuertemente acopladas, esto también facilita la prueba o “testing” de cada uno de los componentes.
Veamos el patrón en acción en C# 2.0, tomado de un ejemplo de nuestro gran amigo y contribuidor a la gran familia de desarrolladores en la WWW David Hayden.public class
BlogDataSource:IBlogDataSource
{
private readonly ILogger _logger;
public BlogDataSource(ILogger logger)
{
_logger = logger;
}
public void AddBlog(Blog blog)
{
_logger.Log(blog.Title);
}
}
Cabe mencionar en este momento que existe 3 formas de implementar DI (Property Setter Injection, Contructor Injection and Interface or Method Injection), de las cuales si buscamos realizar testing de nuestros componentes la decisión indudable para la implementación será Constructor Injection. Revisemos el códigoanterior. El cliente o la clase consumidora para crear en memoria un objecto de esta clase necesita el constructor se lo indica una implementación (es decir otra clase) que implemente los requerimientos de la interface. Para ello cuando necesitamos probar esta clase que para el ejemplo es BlogDataSource si necesidad de tener la implementación de esta interface podemos crear una clase simulada o Mocking que nos sirva de apoyo para revisar el codigo de la clase que queremos probar, de esta manera nuestro componente BlogDataSource es dependiente en su creación en memoria o instanciación pero independiente en su prueba por ello nos podemos asegurarque la lógica que esconde nuestro componente BlogDataSource funciona o no funciona y no se afectado por la dependencia del otro servicio o componente representadopor su interface. Veamos como una clase cliente consumiria nuestro componente
BlogDataSource : public class ClientClass
{
private readonly IBlogDataSource _blogDataSource;
public void Main()
{ ILogger _serviceLogger = new MockingClassLoger(); // Siguiente linea estamos inyectando el servicio del cual depende nuestro otro componente.
IBlogDataSource blogDS = new Blog(_serviceLogger);
blogDS.AddBlog(new Blog());
// Internamente el metodo blog invoco el servicio Looger _logger.Log(blog.Title);
}
}
El punto a destacar aquí es como lo mencionamos anteriormente no necesitamos en nuestras "pruebas" de los servicios de los cualesdepende el componente que desamos probar, así podemos deducir facilmente responsabilidades esto facilita la mantenibilidad de las aplicaciones.En nuestro ejemplo lo que debe de hacer el componente BlogDataSource es invocar el servicio que implementa la interface ILogger si lo hizofunciona sino no funciona listo, es un ejemplo sencillo para poder ejemplificar el punto al que deseo explicar. Sin mas hemos terminado esta exposición sobre el tema de DI y espero continuar escribiendo sobre componentes y sus cualidades, testing que es uno de los objetivos de los mismos.
Recuerde Code4Fun!.
Manolo Herrera
Esto no es nuevo, y viene del mundo java (su mayor expositor el chief scientiest y gurú de los patrones de diseño Martin Fowler http://www.martinfowler.com ), pero Microsoft ha hecho para la comunidad de usuarios de desarrollo de la plataforma .NET una solución muy elegante. Y fue estrenada con las Software Factories, en especial la Web Client Software Factory, que a través de un agente llamado Object Builder de las Microsoft Enterprise Library 3.1 inyecta de manera elegante por medio de atributos que encuentra en las diferentes implementaciones dentro de las WCSF los servicios o componentes dependientes de la clase a crear en memoria. Esto tampoco quiere decir que Microsoft hasta ahora lo esta implementando o lo conoce. Hay artículos del 2005 que hablan ya de esta práctica en la aplicación de este patrón.
Es importante mencionar que el DI no es el único patrón de diseño que soluciona el problema de aplicaciones fuertemente acopladas esta el observer pattern entre otros, que también se utiliza para desacoplar segmentos de código que estaban fuertemente acoplados. Lo interesante de DI es que resuelve un sin número de problemas con distintas implementaciones. También cabe mencionar que Microsoft no es el único que ha hecho una implementación de el patrón DI entre ellos están Casttle Project http://www.castleproject.org/ y Spring Net http://www.springframework.net/ . No obstante la gente de Patterns&Practices ha visto tanto interes en ello que ha creado un nuevo proyecto llamado Unity el cual ahislo de la composite web application block el framework de DI (para los intresados en el proyecto: http://www.codeplex.com/unity ).
Es importante mencionar desde el punto de vista de diseño de patrones que el DI cumple creo yo con dos importantes principios de diseño y son los siguientes:
Favor Composition over inheritance and
Strive for loosely coupled designs between objects that interact.
El primero muchas veces la solución se encuentra en la colaboración de clases a través de interfaces y en la descomposición de una clase en varias y no en la herencia misma que tiene sus pro y contra de esto los patrones de diseño para mas información el libro de Head First Design Patterns es una guía completa de patrones de diseño y un excelente libro para comprenderlos.
El segundo principio que muchos patrones de diseño cumplen se base en las siguientes premisas:
La única cosa que sabe la clase consumidora acerca de la clase proveedora del servicio es que implementa a un contrato o interfase.
No es necesario modificar la clase consumidora si cambiamos o implementamos nuevas funcionalidades en la clase proveedora del servicio o lo único que se mantiene intacto es el contrato que se definió para colaborar entre ellas.
Se puede utilizar independientemente tanto la clase consumidora como el cliente porque no están fuertemente acopladas, esto también facilita la prueba o “testing” de cada uno de los componentes.
Veamos el patrón en acción en C# 2.0, tomado de un ejemplo de nuestro gran amigo y contribuidor a la gran familia de desarrolladores en la WWW David Hayden.public class
BlogDataSource:IBlogDataSource
{
private readonly ILogger _logger;
public BlogDataSource(ILogger logger)
{
_logger = logger;
}
public void AddBlog(Blog blog)
{
_logger.Log(blog.Title);
}
}
Cabe mencionar en este momento que existe 3 formas de implementar DI (Property Setter Injection, Contructor Injection and Interface or Method Injection), de las cuales si buscamos realizar testing de nuestros componentes la decisión indudable para la implementación será Constructor Injection. Revisemos el códigoanterior. El cliente o la clase consumidora para crear en memoria un objecto de esta clase necesita el constructor se lo indica una implementación (es decir otra clase) que implemente los requerimientos de la interface. Para ello cuando necesitamos probar esta clase que para el ejemplo es BlogDataSource si necesidad de tener la implementación de esta interface podemos crear una clase simulada o Mocking que nos sirva de apoyo para revisar el codigo de la clase que queremos probar, de esta manera nuestro componente BlogDataSource es dependiente en su creación en memoria o instanciación pero independiente en su prueba por ello nos podemos asegurarque la lógica que esconde nuestro componente BlogDataSource funciona o no funciona y no se afectado por la dependencia del otro servicio o componente representadopor su interface. Veamos como una clase cliente consumiria nuestro componente
BlogDataSource : public class ClientClass
{
private readonly IBlogDataSource _blogDataSource;
public void Main()
{ ILogger _serviceLogger = new MockingClassLoger(); // Siguiente linea estamos inyectando el servicio del cual depende nuestro otro componente.
IBlogDataSource blogDS = new Blog(_serviceLogger);
blogDS.AddBlog(new Blog());
// Internamente el metodo blog invoco el servicio Looger _logger.Log(blog.Title);
}
}
El punto a destacar aquí es como lo mencionamos anteriormente no necesitamos en nuestras "pruebas" de los servicios de los cualesdepende el componente que desamos probar, así podemos deducir facilmente responsabilidades esto facilita la mantenibilidad de las aplicaciones.En nuestro ejemplo lo que debe de hacer el componente BlogDataSource es invocar el servicio que implementa la interface ILogger si lo hizofunciona sino no funciona listo, es un ejemplo sencillo para poder ejemplificar el punto al que deseo explicar. Sin mas hemos terminado esta exposición sobre el tema de DI y espero continuar escribiendo sobre componentes y sus cualidades, testing que es uno de los objetivos de los mismos.
Recuerde Code4Fun!.
Manolo Herrera
jueves, 21 de febrero de 2008
Tip del dia: Como renombrar una pagina sin bloquer el Visual Studio 2005/2008
Si no le ha pasado, no desarrolla en Web. De repente necesitamos copiar una página Web para utilizarla como base para hacer otra. Esto es muy sencillo pero cuando la estamos renombrando el VS se queda casi trabado, descubrí el procedimiento para obviar este problema. Haga lo siguiente:
Luego de renombrar los archivos físicos, vaya al archivo de código renombre el nombre de la clase al nombre del archivo físico de preferencia y "no grabe", no no lo haga vaya al archivo de
Tip: Una buena practica es si necesitamos agregar nueva funcionalidad o revisar la funcionalidad de la pagina y corregir algún error, no lo haga sobre la versión que esta en producción hágalo con una copia renombrada para no afectar lo que esta puesto en producción y lo que pueda publicarse para no afectar los cambios que aún esta probando. Especialmente si carece de manejo de versiones o no confía en el que esta usando.
Code4Fun!, hasta la próxima!
Manolo Herrera
Suscribirse a:
Entradas (Atom)