Ver por etiquetas

Todas las etiquetas » IoC (RSS)
Buenas! No soy ni mucho menos un experto en EF (es más, me acabo de poner), como pueda serlo p.ej. Unai , pero desde que Scott Guthrie publicó un post sobre EF Code First he empezado a mirar algunas cosillas. Resumiendo rápidamente EF Code First nos permite desarrollar nuestra capa de acceso a datos codificando primero las clases, clases que son POCO . Eso nos permite conseguir lo que se conoce como persistance ignorance (o que las clases que nos representan los datos sean agnósticas sobre cualquier...
Unity , el contenedor IoC de Microsoft, hace algunas semanas que tiene nueva versión: la 2.0. Y viene con algunas novedades interesantes respecto a la versión anterior, que os comento brevemente :) Por fin… un único assembly! Vale que Unity era poco más que un wrapper sobre ObjectBuilder2 pero tampoco era necesario que nos lo recordaran continuamente… ahora ya no tendremos que añadir la referencia a ObjectBuilder2 además de la referencia a Unity cada vez… Ahora existe un solo assembly: Microsoft...
3 comment(s)
Archivado en: ,
Nota: Este post es el segundo post de la serie Objetos que notifican sus cambios de propiedades . En el post anterior vimos como configurar Unity para que no tener que añadir código adicional para implementar la interfaz INotifyPropertyChanged . En este post quiero hablaros de un patrón que se utiliza mucho cuando hablamos de aplicaciones complejas : el patrón del publicador – suscriptor . En este patrón tenemos básicamente dos conceptos: El publicador...
con no comments
Archivado en: ,,
Nota: Este post es el primer post de la serie Objetos que notifican sus cambios de propiedades . En este post vamos a ver como configurar la intercepción de Unity, para poder inyectar nuestro código cada vez que se modifiquen las propiedades de un objeto. Los que desarrolléis en WPF sabréis que existe una interfaz llamada INotifyPropertyChanged , que se puede implementar para notificar a la interfaz de usuario de que las propiedades de un objeto (generalmente ligado a...
con no comments
Archivado en: ,,
Hola a todos!!! Como ha ido la despedida del 2009 y la bienvenida del 2010!!! Espero que os hayáis portado bien y que los reyes os hayan traído muuuuchos regalitos! En este post quiero dejar de lado la serie que estaba haciendo sobre facebook connect, para ver como, gracias a Unity, podemos crear objetos que nos notifiquen cuando cambian sus propiedades, sin que nosotros debamos añadir (casi) ningún código adicional! Pienso que es un muy buen ejemplo del poder de usar un contenedor IoC, además de...
7 comment(s)
Archivado en: ,,
Usar un contenedor de IoC es una práctica más que recomendable, pero al hacerlo es muy fácil caer en el anti-patrón de dependencia con el contenedor . Ese patrón se manifesta de varias formas sútiles, y aunque hay algunos casos en que pueda ser aceptable, en la gran mayoría indica una mala práctica que debemos revisar. ¿Que tiene de malo este código? // IS1 y IS2 son dos interfaces cualesquiera // S1 y S2 son dos clases que implementan dichas interfaces class A { IS1 s1; IS2 s2; public A(IUnityContainer...
4 comment(s)
Archivado en: ,,
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. Resumiendo mucho podemos afirmar que: Con...
1 comment(s)
Archivado en: ,
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. Galcet no comentaba si se refería a aplicaciones desktop o web. En este post voy a tratar aplicaciones de escritorio...
4 comment(s)
Archivado en: ,,
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 ;-) Dependencias de una clase Para entender como funciona la...
4 comment(s)
Archivado en: ,,
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...
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...
5 comment(s)
Archivado en: ,,
Hace algún tiempecillo escribí un artículo para el e-zine de raona , que enviamos a distintos clientes. En el artículo esbozaba los patrones básicos para diseñar interfaces de usuario compuestas. Posteriormente me surgió la idea de que una ampliación de dicho artículo, donde se mostrasen ejemplos en PRISM y WPF de estos conceptos podría ser interesante. Afortunadamente en DotNetMania pensaron lo mismo y es por ello que en la revista...
con no comments
Archivado en: ,,,
No hace mucho, Jorge Dieguez escribió un interesante post sobre Unity y el patrón de Dependency Injection . Resumiendo mucho este patrón permite eliminar las dependencias de nuestro código, trasladandolas todas a un sólo elemento, que se conoce generalmente como “contenedor de DI”. Este contenedor es el responsable de devolvernos todas las referencias a clases que nostros precisemos. Las ventajas es que tenemos un código mucho menos acoplado,...
2 comment(s)
Archivado en: ,,
Hablando con colegas de profesión, me he dado cuenta de que muchos de ellos no terminan de comprender el patrón IoC o las ventajas que su uso comporta… Así que sin ánimo de sentar cátedra he decidido escribir este post, por si le sirve a alguien… J IoC, que corresponde a las siglas de Inversion Of Control, agrupa a varios patrones que tienen en común que el flujo de ejecución del programa se invierte respecto a los métodos de programación tradicionales ( wikipedia dixit ). Generalmente el programador...
14 comment(s)
Archivado en: ,,