[patrones] Inversion of Control and Dependency Injection
Hola Sebastian! Gran pregunta El tema es que en objetos, siempre estamos comunicando instancias. Un objeto A puede necesitar comunicarse con un objeto B. Como consigue el objeto A una referencia a B. De varias formas: alguien se lo pasa como parametro, en un metodo, o alguien se lo paso como parametro en un constructor, o hay una referencia a B en algun lugar estatico, o el propio A lo crea a B, por ejemplo con un new B(). Tambien estan las mismas variantes, pero con FB, una factoria de B: A puede tener una referencia a FB y luego a FB le pide un B. Pero todo esto, de alguna forma, delega a alguien la creacion de un new B en algun momento y en algun punto del codigo. Con una factoria, se podria crear un new B2(), o new B3(), instancias de subclases de B, o de clases que implementen la misma interface que B, etc Pero aun asi, hay casos que el tipo de B es cambiable. De ahi la aparicion del Dependency Injection (A depende de B, pero alguien le inyecta con cual B trabajar). Asi que el patron se aplica, cada vez que A tiene que trabajar con B, pero no sabes de antemano con que tipo especifico de B vas a trabajar. Lo mismo se extiende si B es un simple parametro para A (ejemplo: A es una factoria de conexiones, B es el string de conexion). De ahi, a cuando es bueno usar un patron, esa es una pregunta mas grande. Como todo patron, su uso depende del contexto. Pero podriamos apuntar que el DI permite, por ejemplo, que A, digamos un Entity o Service en la terminologia DDD, se comunique un repositorio B, y alguien le de ese B. Alguna vez le damos B1 (un repositorio que trabaja todo en memoria), otras veces le damos un B2 (un repositorio que va a un DAL nuestro), otras veces un B3 (un repositorio que va contra un ORM). Y en todos esos casos, A nunca toma la decision. El sistema DI (de los cuales pico container, hivemind, spring framework son exponentes en Java, y hasta el mitico AjFramework lo usa de alguna forma :-)...:-), nos permite hacer esos juegos. Estoy escribiendo rapido, mientras actualizo documentos de User Stories, hago un cambio de Team Foundation Server, pienso en el lema de Urysohn para conseguir la metrizacion de espacios topologicos normales, analizo los adjuntos en categorias genericas, y medito sobre algun parrafo de Ser y Tiempo de Heidegger, y leo alguna critica que le hace Ingenieros... si, hoy me olvide de tomarme la pastilla verde... :-) Hoy estoy con la nena... (aclaraciones en http://ajlopez.zoomblog.com/archivo/2006/12/09/estoy-con-la-nena.html) No se si se entendio algo Che, no crossposting, preguntar primero en una lista, y si no hay respuesta, preguntar en otra. Nos leemos! Angel Java Lopez http://www.ajlopez.com/ - Original Message - From: Sebastian Renzi To: patrones List Member Sent: Thursday, December 14, 2006 10:52 AM Subject: [patrones] Inversion of Control and Dependency Injection Buenos días lista, en la lista de DDD mandaron unos links sobre el tema del subject, cuando empecé a leer me di cuenta que es un tema que tiene mucha info para leer, pero me gustaría saber en la practica específicamente cuando surge esta necesidad, en que casos es bueno usar este patrón. Tengo entendido que los chicos de Cooperator habían dicho que usaban este patrón dentro de su framework. Gracias Sebastian Renzi
[patrones] Inversion of Control and Dependency Injection
Jajaja Angel, muy bueno lo de estoy con la nena, a todos nos pasa :) Saludos! rdi2k | Ezequiel Jadib | MSN: [EMAIL PROTECTED] | Blog: ejadib.wordpress.com - Original Message - From: Angel Java Lopez To: patrones List Member Sent: Thursday, December 14, 2006 11:32 AM Subject: [patrones] Inversion of Control and Dependency Injection Hola Sebastian! Gran pregunta El tema es que en objetos, siempre estamos comunicando instancias. Un objeto A puede necesitar comunicarse con un objeto B. Como consigue el objeto A una referencia a B. De varias formas: alguien se lo pasa como parametro, en un metodo, o alguien se lo paso como parametro en un constructor, o hay una referencia a B en algun lugar estatico, o el propio A lo crea a B, por ejemplo con un new B(). Tambien estan las mismas variantes, pero con FB, una factoria de B: A puede tener una referencia a FB y luego a FB le pide un B. Pero todo esto, de alguna forma, delega a alguien la creacion de un new B en algun momento y en algun punto del codigo. Con una factoria, se podria crear un new B2(), o new B3(), instancias de subclases de B, o de clases que implementen la misma interface que B, etc Pero aun asi, hay casos que el tipo de B es cambiable. De ahi la aparicion del Dependency Injection (A depende de B, pero alguien le inyecta con cual B trabajar). Asi que el patron se aplica, cada vez que A tiene que trabajar con B, pero no sabes de antemano con que tipo especifico de B vas a trabajar. Lo mismo se extiende si B es un simple parametro para A (ejemplo: A es una factoria de conexiones, B es el string de conexion). De ahi, a cuando es bueno usar un patron, esa es una pregunta mas grande. Como todo patron, su uso depende del contexto. Pero podriamos apuntar que el DI permite, por ejemplo, que A, digamos un Entity o Service en la terminologia DDD, se comunique un repositorio B, y alguien le de ese B. Alguna vez le damos B1 (un repositorio que trabaja todo en memoria), otras veces le damos un B2 (un repositorio que va a un DAL nuestro), otras veces un B3 (un repositorio que va contra un ORM). Y en todos esos casos, A nunca toma la decision. El sistema DI (de los cuales pico container, hivemind, spring framework son exponentes en Java, y hasta el mitico AjFramework lo usa de alguna forma :-)...:-), nos permite hacer esos juegos. Estoy escribiendo rapido, mientras actualizo documentos de User Stories, hago un cambio de Team Foundation Server, pienso en el lema de Urysohn para conseguir la metrizacion de espacios topologicos normales, analizo los adjuntos en categorias genericas, y medito sobre algun parrafo de Ser y Tiempo de Heidegger, y leo alguna critica que le hace Ingenieros... si, hoy me olvide de tomarme la pastilla verde... :-) Hoy estoy con la nena... (aclaraciones en http://ajlopez.zoomblog.com/archivo/2006/12/09/estoy-con-la-nena.html) No se si se entendio algo Che, no crossposting, preguntar primero en una lista, y si no hay respuesta, preguntar en otra. Nos leemos! Angel Java Lopez http://www.ajlopez.com/ - Original Message - From: Sebastian Renzi To: patrones List Member Sent: Thursday, December 14, 2006 10:52 AM Subject: [patrones] Inversion of Control and Dependency Injection Buenos días lista, en la lista de DDD mandaron unos links sobre el tema del subject, cuando empecé a leer me di cuenta que es un tema que tiene mucha info para leer, pero me gustaría saber en la practica específicamente cuando surge esta necesidad, en que casos es bueno usar este patrón. Tengo entendido que los chicos de Cooperator habían dicho que usaban este patrón dentro de su framework. Gracias Sebastian Renzi
[patrones] Inversion of Control and Dependency Injection
Angel, recién se acaba de ir un empleado de Correo Argentino que me trajo el libro de Jimmy Nilson, y por lo que vi en el índice trae casi un capitulo sobre Inversion of Control and Dependency Injection, así que lo voy a leer un poco mas en detalle y después te cuento como me fue. Este libro viene con ejemplos en c#, pero no vino con ningún CD, los códigos se pueden bajar de algún lado ? _ De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de Angel Java Lopez Enviado el: jueves, 14 de diciembre de 2006 12:30 Para: patrones List Member Asunto: [patrones] Inversion of Control and Dependency Injection Hola gente! Yo haria una aclaracion, para entender hacia donde va DI: Una cosa es desde A llamar a una Abstract Factory para que te de que B usar. Y otra es DI. Por dentro, claro, DI puede usar algun Abstract Factory, o similar. O no, alguien creara A y le hara A.B = new MiB(). Pero la gran vuelta de tuerca, es que A nunca pide nada. Se entrega a la naturaleza y al orden del tiempo. DI proveera. (Cuando lleguemos a Dependecy Injection Operating System, cambiara profundamente el sentido de esa frase:-). A tendra una propiedad B. Y alguien se la proveera. A es pasivo, le llueve B como mana caido del cielo. Nos leemos! Angel Java Lopez http://www.ajlopez.com/ - Original Message - From: Sebastian Renzi mailto:[EMAIL PROTECTED] To: patrones List mailto:patrones@mug.org.ar Member Sent: Thursday, December 14, 2006 12:17 PM Subject: [patrones] Inversion of Control and Dependency Injection Ah, ahora me cae la ficha , estamos hablando de lo mismo .. pero no lo conocía como DI. Resumiendo, para implementar DI usas AF y Reflection. \ __ Información de NOD32, revisión 1921 (20061214) __ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com __ Información de NOD32, revisión 1921 (20061214) __ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com
