[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
[patrones] Inversion of Control and Dependency Injection
Angel gracias por la data, dejame que lo asimile un poco y después respondo. Salutes _ De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de Angel "Java" Lopez Enviado el: jueves, 14 de diciembre de 2006 12:18 Para: patrones List Member Asunto: [patrones] Inversion of Control and Dependency Injection Hola gente! Sebastian, con respecto a 2), B seria un IRepository (una interface) o un RepositoryBase (una clase base de todos los repositorios). Tambien podria ser que A sea el Repositorio, y B un DAL, por ejemplo, y que B1 sea el DAL manual, B2 un DAL via NHibernate, y asi Con respecto a 1), el Abstract Factory le delega la creacion a algo de codigo. Con DI, la creacion la podrias delegar a configuracion, archivos externos, algo que diga de alguna forma, que el B que le corresponde al objeto A es un B2 ahora, y en la proxima ejecucion, cambiando la configuracion, le das un B1. Y eso sin que A vea un abstract factory: simplemente se lo inyecta en general, como parametro en el constructor, o como alguna propiedad. No entendi tu caso Reflection en particular, se me ocurren varios caminos, no se cual tenias en mente La primera vez que "vi la luz" con el DI fue en el libro de Rod Johnson (si, ya se, lo conte mil veces, pero ). One-To-One Expert J2EE Development o algo asi. En el capitulo 9, el bueno de Johnson explica las ventajas de trabajar con Beans que levanta dinamicamente, y los conecta dinamicamente, todo definido desde archivos de configuracion. Muy interesante, de ahi salio el Spring Framework de Java y ahora, el de .NET. Ahora bien, DI se puede usar por codigo, no necesariamente con archivos de configuracion. Pero es muy usado de esta ultima forma, desde que hay frameworks de DI, como los que mencione en el ultimo email. 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:00 PM Subject: [patrones] Inversion of Control and Dependency Injection Angel, antes que nada gracias por la respuesta. Te hago un par de consultas, 1) Que ventajas hay en usar este patrón y no por ejemplo el Abstract Factory, o Reflection ? 2) Específicamente hablando del caso que vos nombras en el Repository (DDD), de que tipo de datos es B dentro de A ?, interface ? Saludos y gracias _ De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de Angel "Java" Lopez Enviado el: jueves, 14 de diciembre de 2006 11:33 Para: patrones List Member Asunto: [patrones] Inversion of Control and Dependency Injection Hola Sebastian! Gran pregunta __ 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
[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 To: patrones List 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. \
[patrones] Inversion of Control and Dependency Injection
Hola gente! Sebastian, con respecto a 2), B seria un IRepository (una interface) o un RepositoryBase (una clase base de todos los repositorios). Tambien podria ser que A sea el Repositorio, y B un DAL, por ejemplo, y que B1 sea el DAL manual, B2 un DAL via NHibernate, y asi Con respecto a 1), el Abstract Factory le delega la creacion a algo de codigo. Con DI, la creacion la podrias delegar a configuracion, archivos externos, algo que diga de alguna forma, que el B que le corresponde al objeto A es un B2 ahora, y en la proxima ejecucion, cambiando la configuracion, le das un B1. Y eso sin que A vea un abstract factory: simplemente se lo inyecta en general, como parametro en el constructor, o como alguna propiedad. No entendi tu caso Reflection en particular, se me ocurren varios caminos, no se cual tenias en mente La primera vez que "vi la luz" con el DI fue en el libro de Rod Johnson (si, ya se, lo conte mil veces, pero ). One-To-One Expert J2EE Development o algo asi. En el capitulo 9, el bueno de Johnson explica las ventajas de trabajar con Beans que levanta dinamicamente, y los conecta dinamicamente, todo definido desde archivos de configuracion. Muy interesante, de ahi salio el Spring Framework de Java y ahora, el de .NET. Ahora bien, DI se puede usar por codigo, no necesariamente con archivos de configuracion. Pero es muy usado de esta ultima forma, desde que hay frameworks de DI, como los que mencione en el ultimo email. Nos leemos! Angel "Java" Lopez http://www.ajlopez.com/ - Original Message - From: Sebastian Renzi To: patrones List Member Sent: Thursday, December 14, 2006 12:00 PM Subject: [patrones] Inversion of Control and Dependency Injection Angel, antes que nada gracias por la respuesta. Te hago un par de consultas, 1) Que ventajas hay en usar este patrón y no por ejemplo el Abstract Factory, o Reflection ? 2) Específicamente hablando del caso que vos nombras en el Repository (DDD), de que tipo de datos es B dentro de A ?, interface ? Saludos y gracias -- De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de Angel "Java" Lopez Enviado el: jueves, 14 de diciembre de 2006 11:33 Para: patrones List Member Asunto: [patrones] Inversion of Control and Dependency Injection Hola Sebastian! Gran pregunta
[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. _ De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de Daniel Calvin Enviado el: jueves, 14 de diciembre de 2006 12:06 Para: patrones List Member Asunto: [patrones] Inversion of Control and Dependency Injection Sebastian Te contesto 1 de metido. 1) Que ventajas hay en usar este patrón y no por ejemplo el Abstract Factory, o Reflection ? Yo implemento DI mediante Abstract Factory y Reflection . Osea, no son competidores, sirven para Saludos Daniel Calvin El día 14/12/06, Sebastian Renzi <[EMAIL PROTECTED]> escribió: Angel, antes que nada gracias por la respuesta. Te hago un par de consultas, 1) Que ventajas hay en usar este patrón y no por ejemplo el Abstract Factory, o Reflection ? 2) Específicamente hablando del caso que vos nombras en el Repository (DDD), de que tipo de datos es B dentro de A ?, interface ? Saludos y gracias _ De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de Angel "Java" Lopez Enviado el: jueves, 14 de diciembre de 2006 11:33 Para: patrones List Member Asunto: [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 <mailto:[EMAIL PROTECTED]> Renzi To: patrones List Member <mailto:patrones@mug.org.ar> 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 __ Información de NOD32, revisión 1921 (20061214) __ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com <http://www.nod32
[patrones] Inversion of Control and Dependency Injection
La canción esta muy bien http://www.domaindrivendesign.org/funstuff/index.html Disculpen
[patrones] Inversion of Control and Dependency Injection
Sebastian Te contesto 1 de metido. 1) Que ventajas hay en usar este patrón y no por ejemplo el Abstract Factory, o Reflection ? Yo implemento DI mediante Abstract Factory y Reflection . Osea, no son competidores, sirven para Saludos Daniel Calvin El día 14/12/06, Sebastian Renzi <[EMAIL PROTECTED]> escribió: Angel, antes que nada gracias por la respuesta. Te hago un par de consultas, 1) Que ventajas hay en usar este patrón y no por ejemplo el Abstract Factory, o Reflection ? 2) Específicamente hablando del caso que vos nombras en el Repository (DDD), de que tipo de datos es B dentro de A ?, interface ? Saludos y gracias -- *De:* patrones@mug.org.ar [mailto:[EMAIL PROTECTED] *En nombre de *Angel "Java" Lopez *Enviado el:* jueves, 14 de diciembre de 2006 11:33 *Para:* patrones List Member *Asunto:* [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 <[EMAIL PROTECTED]> *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 __ 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 -- Daniel A. Calvin Cooperator Team Member http://www.cooperator.com.ar Microsoft Certified Professional
[patrones] Inversion of Control and Dependency Injection
Angel, antes que nada gracias por la respuesta. Te hago un par de consultas, 1) Que ventajas hay en usar este patrón y no por ejemplo el Abstract Factory, o Reflection ? 2) Específicamente hablando del caso que vos nombras en el Repository (DDD), de que tipo de datos es B dentro de A ?, interface ? Saludos y gracias _ De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de Angel "Java" Lopez Enviado el: jueves, 14 de diciembre de 2006 11:33 Para: patrones List Member Asunto: [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 <mailto:[EMAIL PROTECTED]> To: patrones List <mailto:patrones@mug.org.ar> 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 __ 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
[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
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
Te suscribis desde el site de Evans www.domaindrivendesign.org <http://www.domaindrivendesign.org/> . Es una de Yahoo Groups : [EMAIL PROTECTED] _ De: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de julio.novomisky Enviado el: jueves, 14 de diciembre de 2006 11:24 Para: patrones List Member Asunto: [patrones] Inversion of Control and Dependency Injection Sebastian, Cual es la lista de DDD? Gracias por la respuesta Julio -Original Message- From: "Sebastian Renzi" <[EMAIL PROTECTED]> To: "patrones List Member" Date: Thu, 14 Dec 2006 10:52:47 -0300 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
Sebastian, Cual es la lista de DDD? Gracias por la respuesta Julio -Original Message- From: "Sebastian Renzi" <[EMAIL PROTECTED]> To: "patrones List Member" Date: Thu, 14 Dec 2006 10:52:47 -0300 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
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