Comentarios en: Inyección de Dependencia con Spring.Net http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/ responsabilidad del objeto: bloguear Sat, 31 Oct 2009 09:59:00 +0000 http://wordpress.com/ hourly 1 Por: Raul http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-486 Raul Wed, 23 Jul 2008 17:33:06 +0000 http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-486 Hola, Probe el ejemplo y funciona. Pero cuando le hago una modificación deja de funcionar. Por ejemplo, probe agragar un objeto Cliente2 igual a cliente y no funciona. Con solo agregar este Cliente2 debajo de objeto Cliente en la configuración tira una Exeption. También probe renombrando a Cliente, como objeto único y no anda tampoco. No entiendo que sucede con este ejemplo. Hola, Probe el ejemplo y funciona. Pero cuando le hago una modificación deja de funcionar. Por ejemplo, probe agragar un objeto Cliente2 igual a cliente y no funciona. Con solo agregar este Cliente2 debajo de objeto Cliente en la configuración tira una Exeption. También probe renombrando a Cliente, como objeto único y no anda tampoco. No entiendo que sucede con este ejemplo.

]]> Por: Indirect http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-482 Indirect Thu, 19 Jun 2008 14:46:14 +0000 http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-482 Somehow i missed the point. Probably lost in translation :) Anyway ... nice blog to visit. cheers, Indirect! Somehow i missed the point. Probably lost in translation :) Anyway … nice blog to visit.

cheers, Indirect!

]]> Por: Dario Quintana http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-41 Dario Quintana Fri, 29 Dec 2006 17:31:11 +0000 http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-41 Es cierto, con interfaces hablamos sobre la descripción de comportamientos y es justamente los que necesitamos, por eso las usamos. Debemos saber exactamente que tiene que hacer alguien implemente una interfaz, sin importar como lo haga. Tiene sus diferencias el hablar de clases Abstractas e Interfaces, aunque en algunos ambientes no importe que usemos. El tema aquí es que nosotros estamos estableciendo un compromiso contractual entre las clases que quieran implementar ICliente, de modo que sí o sí debemos dar una implementación de todos los methods/properties en las clases que heredan/implementan de ICliente. En una clase abstracta, no se dá esto, es decir, puedo en una clase derivada de AbstractCliente, no implementar un metodo ó una propiedad y optar hacerlo en una proxima derivada. Otra cosa importante, es que al hablar de una clase abstracta (si bien no se puede instanciar) ya estamos hablando de una implementación, que puede ser mínima o no, y esto es justamente lo que estamos queriendo desacoplar, la implementación. Podría ser válido tener una clase AbstractCliente que implementa ICliente, y despues podríamos hacer que Cliente herede de AbstractCliente, pero en mi opinión no creo que justifique el esfuerzo, no creo que haya mucho que escribir en AbstractCliente. Por cierto, muy buenos los comentarios! Saludos Es cierto, con interfaces hablamos sobre la descripción de comportamientos y es justamente los que necesitamos, por eso las usamos. Debemos saber exactamente que tiene que hacer alguien implemente una interfaz, sin importar como lo haga.

Tiene sus diferencias el hablar de clases Abstractas e Interfaces, aunque en algunos ambientes no importe que usemos.

El tema aquí es que nosotros estamos estableciendo un compromiso contractual entre las clases que quieran implementar ICliente, de modo que sí o sí debemos dar una implementación de todos los methods/properties en las clases que heredan/implementan de ICliente.
En una clase abstracta, no se dá esto, es decir, puedo en una clase derivada de AbstractCliente, no implementar un metodo ó una propiedad y optar hacerlo en una proxima derivada.
Otra cosa importante, es que al hablar de una clase abstracta (si bien no se puede instanciar) ya estamos hablando de una implementación, que puede ser mínima o no, y esto es justamente lo que estamos queriendo desacoplar, la implementación. Podría ser válido tener una clase AbstractCliente que implementa ICliente, y despues podríamos hacer que Cliente herede de AbstractCliente, pero en mi opinión no creo que justifique el esfuerzo, no creo que haya mucho que escribir en AbstractCliente.

Por cierto, muy buenos los comentarios!
Saludos

]]> Por: Emilio Velardiez http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-40 Emilio Velardiez Fri, 29 Dec 2006 11:51:31 +0000 http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-40 Hola Dario, Hasta donde yo se de POO el uso de Interfaces tienen que ver con la descripción de comportamientos, como ejemplos ISerializable o IDataBound. Creo que el uso que hacemos de "ICliente" se aproxima más a la de una clase abstracta y no a la de una Interfaz. No se que opináis al respecto? Saludos. Hola Dario,

Hasta donde yo se de POO el uso de Interfaces tienen que ver con la descripción de comportamientos, como ejemplos ISerializable o IDataBound. Creo que el uso que hacemos de “ICliente” se aproxima más a la de una clase abstracta y no a la de una Interfaz. No se que opináis al respecto?

Saludos.

]]> Por: Dario Quintana http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-39 Dario Quintana Fri, 29 Dec 2006 06:14:27 +0000 http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-39 Emilio, GLM respondió por mí. Al usar la interfaz ICliente, usas el intellisense sin problemas, que es un accidente de que se puedan ocupar los metodos, sino no tenés cómo trabajar con los métodos/properties/fields de Cliente. Ahora bien, cual es la mayor diferencia entre Activator.CreateInstance(assembly,type) y lo que está haciendo Spring en el ejemplo ? CreateInstance es una función y Spring es un feroz framework :) ahora... hablando solamente de la instanciación...ninguna. Convengamos que la inyección por Spring te dá mucho vuelo (es un framework no?), con solo poner singleton=true ténes el singletón cocinado. Aparte la instanciación se está realizando para un contexto, que en otra app, el contexto puede es otro y puede q cambiar la implementación...y esto se complica programandolo sin un framework q te ayude. Con respecto a los plugins...esto es lo que se usa, no tenés otra (q yo conozca). Cambiarle las palabras/framework/helper hechos por nosotros, pero tarde o temprano tenes que usar estos principios. Y como nombraba entre todos los containers que te permiten hacer IoC el ObjectBuilder es escrito por los muchachos de Patterns and Practices y es lo que se ocupa en los App Blocks (el link está al comienzo del post) Que opinan ? Emilio, GLM respondió por mí. Al usar la interfaz ICliente, usas el intellisense sin problemas, que es un accidente de que se puedan ocupar los metodos, sino no tenés cómo trabajar con los métodos/properties/fields de Cliente.

Ahora bien, cual es la mayor diferencia entre Activator.CreateInstance(assembly,type) y lo que está haciendo Spring en el ejemplo ? CreateInstance es una función y Spring es un feroz framework :) ahora… hablando solamente de la instanciación…ninguna. Convengamos que la inyección por Spring te dá mucho vuelo (es un framework no?), con solo poner singleton=true ténes el singletón cocinado. Aparte la instanciación se está realizando para un contexto, que en otra app, el contexto puede es otro y puede q cambiar la implementación…y esto se complica programandolo sin un framework q te ayude.

Con respecto a los plugins…esto es lo que se usa, no tenés otra (q yo conozca). Cambiarle las palabras/framework/helper hechos por nosotros, pero tarde o temprano tenes que usar estos principios.

Y como nombraba entre todos los containers que te permiten hacer IoC el ObjectBuilder es escrito por los muchachos de Patterns and Practices y es lo que se ocupa en los App Blocks (el link está al comienzo del post)

Que opinan ?

]]> Por: GLM http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-38 GLM Fri, 29 Dec 2006 02:03:14 +0000 http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-38 Emilio: evidentemente al hacer una instanciacion de un objeto que no lo tiene referenciado, pierde el intellisense del objeto en si (porque la referencia no esta en el proyecto), pero Dario deberia tener la interface ICliente bien conocida (referenciada) en su proyecto, por lo que el trata en la aplicacion al objeto como un ICliente, y tiene intellisense de ICliente. Podes pensarlo, si se te hace mas facil, como que ICliente es una clase base, y por lo tanto tenes acceso al intellisense. De hecho es valido usar una clase base para este tipo de escenarios, pero no estoy seguro si Spring.Net lo soporta. Saludos Emilio: evidentemente al hacer una instanciacion de un objeto que no lo tiene referenciado, pierde el intellisense del objeto en si (porque la referencia no esta en el proyecto), pero Dario deberia tener la interface ICliente bien conocida (referenciada) en su proyecto, por lo que el trata en la aplicacion al objeto como un ICliente, y tiene intellisense de ICliente.
Podes pensarlo, si se te hace mas facil, como que ICliente es una clase base, y por lo tanto tenes acceso al intellisense. De hecho es valido usar una clase base para este tipo de escenarios, pero no estoy seguro si Spring.Net lo soporta.

Saludos

]]> Por: GLM http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-37 GLM Fri, 29 Dec 2006 01:53:15 +0000 http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-37 Cual es la mayor diferencia... Estoy hablando nada mas y nada menos de Activator.CreateInstance(assembly, type); o sea lo que veo es que Spring.net va a buscar el solo un objeto (¿Cualkiera?) que implemente ICliente y te lo tira... es algo un poco menos especifico que CreateInstance... Recientemente estuve viendo el codigo de un plug in del Reflector de Lutz... y miraba como implementaba la conexion con la aplicacion host, es un tipico ejemplo ya que habia una linea: Reflector.ILoQueSea = this.plugInContext.GetLoQueSea(); (no era lo que sea, sino una de las tantas interfaces que expone Reflector, pero no es lo importante) Dario, Podriamos usar este tipo de cosas para implementar un soporte de plugins? Hablando de plugins los nuevos aplication blocks traen un block para esto Muy buen post! Saludos Cual es la mayor diferencia…

Estoy hablando nada mas y nada menos de Activator.CreateInstance(assembly, type);

o sea lo que veo es que Spring.net va a buscar el solo un objeto (¿Cualkiera?) que implemente ICliente y te lo tira… es algo un poco menos especifico que CreateInstance…

Recientemente estuve viendo el codigo de un plug in del Reflector de Lutz… y miraba como implementaba la conexion con la aplicacion host, es un tipico ejemplo ya que habia una linea: Reflector.ILoQueSea = this.plugInContext.GetLoQueSea();
(no era lo que sea, sino una de las tantas interfaces que expone Reflector, pero no es lo importante)
Dario, Podriamos usar este tipo de cosas para implementar un soporte de plugins? Hablando de plugins los nuevos aplication blocks traen un block para esto
Muy buen post!

Saludos

]]> Por: Emilio Velardiez http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-36 Emilio Velardiez Thu, 28 Dec 2006 22:00:53 +0000 http://darionet.wordpress.com/2006/12/28/inyeccin-de-dependencia-con-springnet/#comment-36 Hola, Cuando desarrollas con este tipo de fmks AOP que proporciona la reflexion pierdes la productividad que otorga el Intellisense del ensamblado que reflexionas? Saludos. Hola,

Cuando desarrollas con este tipo de fmks AOP que proporciona la reflexion pierdes la productividad que otorga el Intellisense del ensamblado que reflexionas?

Saludos.

]]>