[patrones] Inversion of Control and Dependency Injection

2006-12-14 Por tema Sebastian Renzi
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

2006-12-14 Por tema Sebastian Renzi
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

2006-12-14 Por tema Angel \"Java\" Lopez
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

2006-12-14 Por tema Angel \"Java\" Lopez
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

2006-12-14 Por tema Sebastian Renzi
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

2006-12-14 Por tema David Ibaceta

La canción esta muy bien
http://www.domaindrivendesign.org/funstuff/index.html

Disculpen


[patrones] Inversion of Control and Dependency Injection

2006-12-14 Por tema Daniel Calvin

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

2006-12-14 Por tema Sebastian Renzi
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

2006-12-14 Por tema Ezequiel Jadib
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

2006-12-14 Por tema Angel \"Java\" Lopez
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

2006-12-14 Por tema Sebastian Renzi
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

2006-12-14 Por tema julio.novomisky

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

2006-12-14 Por tema Sebastian Renzi
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