Hola a todos!! Este año tengo el placer de realizar una presentación en las ALM Sessions’09.
En concreto hablaré sobre Test Driven Development: que és, como su uso junto con otras buenas prácticas de desarrollo puede ayudarnos a ganar en calidad y como podemos implantarlo en un equipo de desarrollo.
Los que leais habitualmente mi blog (¡muchas gracias!) habreis visto que tengo varias entradas sobre unity el contenedor IoC de la gente de patterns & practices. En ellas he ido comentando varios aspectos más o menos avanzados del contenedor y de los patrones IoC associados.
En este post quiero hablaros un poco de los “lifetime managers”, objetos que le indican a Unity si cuando debe resolver un objeto debe crear uno nuevo o bien devolver uno existente.
Te has preguntado alguna vez la diferencia de rendimiento que pueda haber entre el método extensor Count() proporcionado por LINQ y la propiedad Count de la interfaz IList
Buenas! Como prometí en el post anterior sobre el CodeCamp, en mi charla sobre Code Contracts, quedaron por ver algunos temillas que aprovecho para comentar ahora.
Pues sí… han pasado ya dos días, pero yo todavía estoy resacoso del Code Camp 2009 de Tarragona.
Fue una experiencia brutal, tanto en lo organizativo, como en lo técnico pero sobretodo en lo humano… compartir este fin de semana con gente apasionada de la tecnología .NET, sea en entornos MS o en Mono, es simplemente increíble.
Un comentario de Galcet en mi post “Como independizar tu capa lógica de tu capa de presentación” decía que el entendía por separado los conceptos de IoC y los de MVC pero que no veía como podían trabajar juntos… El motivo de este post es para comentar precisamente esto: no sólo cómo MVC e IoC pueden trabajar juntos sinó las ventajas que la combinación de ambos patrones nos aporta.
Hace ya algún tiempecillo publiqué por aquí un post sobre IoC, titulado IoC o el poder de ceder el control. En el post mencionaba dos de los patrones clásicos asociados con IoC, el service locator y la inyección de dependencias (dependency injection), pero luego sólo me centraba en Service Locator. Un par de comentarios en dicho post decían si era posible algo similar pero explicando la inyección de dependencias, así que a ello vamos 😉
Que es una buena práctica usar un contenedor IoC hoy en día es algo que está más que aceptado… la gente que montó ASP.NET MVC lo tiene muy claro y por eso ha creado un framework, que aunque no usa ningún contenedor IoC por defecto, se puede extender para usar uno… P.ej. si quieres que tus controladores sean creados a través de un contenedor IoC (y deberías querrerlo) solo debes crearte una factoría de controladores e indicar a ASP.NET MVC que use esta factoría en lugar de la que viene por defecto.
Hola a todos!! Este post continua la mini-serie de posts que empecé con el que trataba sobre las áreas.
En este caso he estado jugando un poco con lo que llaman UI helper templating support y que me parece bastante interesante…
En mi opinión, usar un contenedor de IoC hoy en día, no es una opción sinó una obligación. Las ventajas que nos ofrecen son incotestables. Los patrones Service Locator y Dependency Injection nos permiten desacoplar nuestro código, y son la base para poder trabajar de forma modular y poder generar unos tests unitarios de forma más sencilla. Pero hoy no quiero hablaros de ninguno de estos patrones, sinó de otra de las capacidades de los contenedores de IoC: la generación de proxies.