Ta, no te quiero convencer de que uses un framework, simplemente de que el problema y su solución es la misma, sea IoC a la Leonardo o la Spring. :D
Saludos El día 24 de junio de 2008 10:41, Leonardo Micheloni < [EMAIL PROTECTED]> escribió: > Hola Daniel > Gracias por tu infinita paciencia, de todos modos tengo algunas > reservas con respecto a utilizar un framework de IoC, más allá del > ciclo de vida de los objetos no veo mucha ventaja, aunque dentro de > todo ninject me convence más por el tema de la configuración, pero > spring...mmmm, no sé, pero bueno, soy medio cabeza dura, gracias a > todos. > > Saludos, > > 2008/6/24 Carlos Peix <[EMAIL PROTECTED]>: > > Hola Leonardo, > > > > La respuesta al planteo que me haces en tu mail anterior es la que da > > Daniel. Por supuesto que todos tus factories dependen del wrapper, ese > es, > > en todo caso, el acoplamiento bueno, el malo seria que quedara acoplado > al > > framework. > > > > Pero, aquí vale mas que nunca mi frase de ultimo mail. La valoracion del > > acoplamiento es bastante subjetiva. > > > > Un abrazo. > > > > > > Buscamos desarrolladores .NET (CV a [EMAIL PROTECTED]) > > Carlos Peix > > [EMAIL PROTECTED] > > tel: 4257-4622 > > cel: 15-4406-7571 > > > > -----Mensaje original----- > > De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de > Leonardo > > Micheloni > > Enviado el: Martes, 24 de Junio de 2008 08:45 a.m. > > Para: [email protected] > > Asunto: [puntonet] Re: Re: Re: RE: [puntonet] Re: RE: [puntonet] Re: RE: > > [puntonet] Inversión de controls vs Factory > > > > Entonces estoy pegado al wrapper en todos los Factory, no es lo mismo? > > > > Leonardo Micheloni. > > > > 2008/6/24 Daniel Calvin <[EMAIL PROTECTED]>: > >> Te equivocas Leonardo, vos debes wrapear el framework que uses e > >> invocar ese wrapper. El unico acoplado al framework de IoC es el > >> wrapper. Tu factory solo conoce al wrapper. Si cambias el framework solo > > impacta en el wrapper. > >> > >> Daniel Calvin > >> > >> El día 23 de junio de 2008 23:53, Leonardo Micheloni > >> <[EMAIL PROTECTED]> escribió: > >>> > >>> Hola Carlos, > >>> Eso lo tengo clarísimo, lo que no veo como instanciás > >>> FachadaDeNegocio sin hacer referencia al framework IoC, que según tu > >>> ejemplo es quien sabe cómo se construye un objeto y cómo se inyecta > >>> IRepositorioX. Según lo que yo creo con un Factory que dentro llama > >>> al framework IoC o lo hace "harcodeado", ahí es dónde me viene la > >>> duda, si puedo resolverlo con el Factory a mano, por qué voy a usar > >>> un framework IoC que me centraliza toda la construcción de los > >>> objetos, para mí eso es acoplamiento global, todos los factory van a > >>> llamar al mismo objeto, el facade del IoC o lo que sea para que > >>> resuelva la creación de los objetos. O sea, si cambio el framework > >>> IoC tengo que modificar todos los Factory, o me equivoco? > >>> > >>> Saludos > >>> > >>> > >>> 2008/6/23 Carlos Peix <[EMAIL PROTECTED]>: > >>> > Hola Leonardo, > >>> > > >>> > Antes de seguir en esta discusion creo conveniente aclarar que la > >>> > VALORACION acoplamiento (o de metricas tales como fan-in o fan-out) > >>> > es bastante subjetiva. Dicho esto sigo con mi explicacion porque > >>> > creo que no logre explicarme bien. > >>> > > >>> > Vos decis: "Respecto a lo de la frase de aumento de acoplamiento es > >>> > justamente porque todos van a llamar al IoC o sea, todos van a > >>> > estar acoplados en un punto, o hay otra cosas más que no sé?". > >>> > Interpreto que vos asumis que el cliente de un determinado servicio > >>> > necesita referenciar al framework de IoC para obtener ese servicio, > >>> > pero no es asi. > >>> > > >>> > Ejemplo: > >>> > > >>> > // Teniendo una interfaz > >>> > public interface IRepositorioX {} > >>> > > >>> > // y un cliente (por ejemplo por constructor injection) public > >>> > class FachadaDeNegocio { > >>> > IRepositorioX repositorioX; > >>> > public FachadaDeNegocio( IRepositorioX repositorioX ) > >>> > { > >>> > this.repositorioX = repositorioX; > >>> > } > >>> > } > >>> > > >>> > Fijate que en este esquema, el cliente no tiene ninguna referencia > >>> > a la implementacion de la interfaz. Esto es justamente lo que > >>> > resuelve el framework de IoC. Fijate tambien que no hace ninguna > >>> > referencia al engine de IoC tampoco. > >>> > > >>> > Espero haber aclarado. > >>> > > >>> > > >>> > Buscamos desarrolladores .NET (CV a [EMAIL PROTECTED]) Carlos Peix > >>> > [EMAIL PROTECTED] > >>> > tel: 4257-4622 > >>> > cel: 15-4406-7571 > >>> > > >>> > -----Mensaje original----- > >>> > De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de > >>> > Leonardo Micheloni Enviado el: Lunes, 23 de Junio de 2008 03:37 > >>> > p.m. > >>> > Para: [email protected] > >>> > Asunto: [puntonet] Re: RE: [puntonet] Re: RE: [puntonet] Inversión > >>> > de controls vs Factory > >>> > > >>> > Gracias por la respuesta, > >>> > Estamos de acuerdo que todo lo acoplamos con interfaces, de eso no > >>> > hay duda, pero si en lugar de instanciar un objeto con un IoC > >>> > llamamos a un Factory que sabe cómo crearlo, no es lo mismo? ahora > >>> > sí, tenés razón, está la ventaja del ciclo de vida manejado, eso sí > >>> > lo veo como una ventaja con respecto al Factory pero tampoco es que > >>> > no se pueda hacer de otra manera. > >>> > Con un Factory usando Interfaces tampoco tenés que modificar nada > >>> > si agregás un servicio para que depende la clase de él e inyectás > >>> > por constructor la dependencia. > >>> > Respecto a lo de la frase de aumento de acoplamiento es justamente > >>> > porque todos van a llamar al IoC o sea, todos van a estar acoplados > >>> > en un punto, o hay otra cosas más que no sé? (esto contesta también > >>> > a > >>> > Daniel) > >>> > Lo que digo es, estoy muy loco o se puede prescindir de los IoC > >>> > haciendo un buen uso de Factory + Interfaces? Esto hablando de una > >>> > aplicación normal, si hacemos un framework estamos de acuerdo que > >>> > por la dinámica de las cosas es indispensable un IoC. > >>> > > >>> > Gracias, > >>> > > >>> > 2008/6/23 Carlos Peix <[EMAIL PROTECTED]>: > >>> >> Bien, gracias por la ampliacion, > >>> >> > >>> >> Usar IoC en objetos de negocio es un camino riesgoso. No siempre > >>> >> es facil intervenir en la creacion de estos objetos, por ejemplo > >>> >> cuando hay un ORM de por medio. Incluso a mi no me gustaria pegar > >>> >> "tanto" los objetos de negocio con los servicios, es por el mismo > >>> >> motivo que no me gusta usar constructor o setter injection (porque > >>> >> si el objeto necesita un servicio adicional, debo modificar el > >>> >> constructor, factory, > >>> > etc). > >>> >> > >>> >> Prefiero, un registro universalmente disponible (registry + > > singleton). > >>> >> > >>> >> Las ventajas de los frameworks IoC vienen junto con molestia, no > >>> >> hay dudas de eso. La unica que veo, sin embargo, es la > >>> >> complejidad, por eso me gustaria saber que es lo que motiva tu > frase: > >>> >> > >>> >>> ...en realidad la > >>> >>> pregunta es por qué debería utilizar inversión de control (con > >>> >>> winsor, unity, spring, ninject o lo que sea), me parece que > >>> >>> aumenta el acoplamiento... > >>> >> > >>> >> No veo porque Winsor te aumenta la dependencia, incluso diria que > >>> >> la disminuye. Si vos tenes que injectar una instancia de un > >>> >> servicio (por ejemplo un repositorio) en una fachada de servicio, > >>> >> vas a tener que crearla y para crearla, vas a tener una > >>> >> dependencia de la clase concreta que implementa el repositorio. Si > >>> >> usas Winsor, en ningun lugar de tus fachadas de servicios tenes > >>> >> que referir las clases concretas, con la interfaz alcanza, lo > >>> >> cual, para mi, es menos > >>> > acoplamiento. > >>> >> > >>> >> Otra ventaja muy importante, en mi opinion, de los framework de > >>> >> IoC es que te manejar en ciclo de vida de los servicios y objetos > > asociados. > >>> >> > >>> >> Un abrazo > >>> >> > >>> >> > >>> >> Buscamos desarrolladores .NET (CV a [EMAIL PROTECTED]) Carlos > >>> >> Peix [EMAIL PROTECTED] > >>> >> tel: 4257-4622 > >>> >> cel: 15-4406-7571 > >>> >> > >>> >> -----Mensaje original----- > >>> >> De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de > >>> >> Leonardo Micheloni Enviado el: Lunes, 23 de Junio de 2008 02:53 p.m. > >>> >> Para: [email protected] > >>> >> Asunto: [puntonet] Re: RE: [puntonet] Inversión de controls vs > >>> >> Factory > >>> >> > >>> >> Hola Carlos, > >>> >> Objetos de negocios, como le digo a Angel no veo la necesidad de > >>> >> un IoC realmente, de echo sólo veo más complejidad que no tiene un > >>> >> beneficio tangible inmediato o tan claro, esa es mi duda. De todos > >>> >> modos si fueran servicio tampoco veo la ventaja. > >>> >> > >>> >> 2008/6/23 Carlos Peix <[EMAIL PROTECTED]>: > >>> >>> Hola Leonardo, > >>> >>> > >>> >>> Va mi opinion con aclaraciones. Vos no mencionas que tipos de > >>> >>> objetos son los que crearias mediante factories con el fin de > >>> >>> inyectarle las dependencias y es necesario que lo aclares porque > >>> >>> la respuesta puede ser distinta dependiendo de esto. > >>> >>> > >>> >>> Si fueran objetos de logica de negocio, la factory es una buena > >>> >>> salida. Si en cambio fuesen otro tipo de objetos (una capa de > >>> >>> servicios por ejemplo), no veo inconveniente en usar un framework > >>> >>> de IoC, incluso creo que esa es la opcion que menos dependencia > > genera. > >>> >>> > >>> >>> Hay una discusion eterna en la lista DDD sobre si los objetos de > >>> >>> dominio tienen o no tienen que tener referencias a repositorios y > >>> >>> otros servicios de infraestructura. Mi opinion al respecto aun no > >>> >>> esta definida porque quiero investigar un poco mas si es posible > >>> >>> o no prescindir de los repositorios en los objetos de negocio, > >>> >>> estoy esperando el proximo proyecto de estudio para eso. > >>> >>> > >>> >>> No obstante, si fueran necesarios, la discusion es si se inyectan > >>> >>> mediante un framework o el codigo dentro del objeto busca el > >>> >>> repositorio desde una registry de servicios. > >>> >>> > >>> >>> Yo prefiero la segunda opcion porque me parece mas flexible, los > >>> >>> detractores la critican porque dicen que hace dificil el unit > > testing. > >>> >>> Yo no tengo este problema porque uso reflection o Castle Windsor > >>> >>> para inyectar la implementacion de los servicios en la registry. > >>> >>> > >>> >>> De todas maneras, creo que seria bueno que los objetos de dominio > >>> >>> no dependiesen para nada de los servicios, pero aun tengo que > >>> >>> demostrarme que esto es posible. > >>> >>> > >>> >>> > >>> >>> Buscamos desarrolladores .NET (CV a [EMAIL PROTECTED]) Carlos > >>> >>> Peix [EMAIL PROTECTED] > >>> >>> tel: 4257-4622 > >>> >>> cel: 15-4406-7571 > >>> >>> > >>> >>> -----Mensaje original----- > >>> >>> De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de > >>> >>> Leonardo Micheloni Enviado el: Lunes, 23 de Junio de 2008 11:27 > a.m. > >>> >>> Para: [email protected] > >>> >>> Asunto: [puntonet] Inversión de controls vs Factory > >>> >>> > >>> >>> Hola a todos, > >>> >>> Mando la pregunta a esta lista porque tengo problemas con la de > >>> >>> arquitectura, me rechaza los mensajes y creo que la mayoría de la > >>> >>> gente de esa lista está en esta. > >>> >>> > >>> >>> La cosa es así, estoy metiendo mano en una aplicación para hacer > >>> >>> unos cambios, el tema es que es bastante compleja y delicada > >>> >>> también y también está bastante mal en el sentido del diseño, > >>> >>> tiene mucho acopalmiento, con lo cual es muy difícil de probar > >>> >>> los cambios que tengo que hacer sin correr la aplicación. Por lo > >>> >>> tanto como quiero tener pruebas unitarias para todo lo que voy a > >>> >>> hacer y de paso para algunos procesos que no voy a tocar ya que > >>> >>> tengo algunos días para esto y > >>> >> de paso lo dejo con un buen "code coverage" > >>> >>> se me plantea la tarea de rediseñar algunas cosas. > >>> >>> Entre otras el tema del acomplamiento me lleva a cambiar la > >>> >>> forma en que se instancian algunas clases y inyectarles > >>> >>> dependencia, es decir, que por el constructor se pasen interfaces > >>> >>> de otras clases que usa internamente para faciliar inyectar "mock > >>> >>> objects" para las pruebas unitarias (hacerlas bien unitarias), ok > >>> >>> hasta ahí todo bien. El tema es que no me queda muy claro si > >>> >>> utilizar un partón factory para la creación de los objetos (ahora > >>> >>> la instanciación en más compleja por la inyección de depencias) o > >>> >>> inversión de control, en realidad la pregunta es por qué debería > >>> >>> utilizar inversión de control (con winsor, unity, spring, ninject > >>> >>> o lo que sea), me parece que aumenta el acoplamiento y más que > >>> >>> nada los modelos basados en configuración hace más difícil > >>> >>> comprender el sistema. Antes que se me tiren en palomita, les doy > >>> >>> mi impresión, con factory se puede resover todo lo mismo que con > >>> >>> inversión de control y no tenemos todo un sistema "pegado" a un > >>> >>> punto, > >>> >> me gustaría conocer su opinión. > >>> >>> > >>> >>> Gracias y saludos. > >>> >>> > >>> >>> -- > >>> >>> Leonardo Micheloni. > >>> >>> Ayudando a organizar las primeras jornadas ágiles de > >>> >>> Latinoamérica > >>> >>> > >>> >>> http://agiles2008.org/ > >>> >>> > >>> >>> Blog Personal > >>> >>> > >>> >>> http://leomicheloni.blogspot.com/ > >>> >>> http://multithreadingincsharp.blogspot.com/ > >>> >>> > >>> >>> > >>> >>> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> Leonardo Micheloni. > >>> >> Ayudando a organizar las primeras jornadas ágiles de Latinoamérica > >>> >> > >>> >> http://agiles2008.org/ > >>> >> > >>> >> Blog Personal > >>> >> > >>> >> http://leomicheloni.blogspot.com/ > >>> >> http://multithreadingincsharp.blogspot.com/ > >>> >> > >>> >> > >>> >> > >>> > > >>> > -- > >>> > Leonardo Micheloni. > >>> > Ayudando a organizar las primeras jornadas ágiles de Latinoamérica > >>> > > >>> > http://agiles2008.org/ > >>> > > >>> > Blog Personal > >>> > > >>> > http://leomicheloni.blogspot.com/ > >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> -- > >>> Leonardo Micheloni. > >>> Ayudando a organizar las primeras jornadas ágiles de Latinoamérica > >>> > >>> http://agiles2008.org/ > >>> > >>> Blog Personal > >>> > >>> http://leomicheloni.blogspot.com/ > >>> > >> > >> > >> > >> -- > >> Daniel A. Calvin > >> Cooperator Team Member > >> http://www.cooperator.com.ar > >> Microsoft Certified Professional > > > > > > > > > > -- > Leonardo Micheloni. > Ayudando a organizar las primeras jornadas ágiles de Latinoamérica > > http://agiles2008.org/ > > Blog Personal > > http://leomicheloni.blogspot.com/ > > -- Daniel A. Calvin Cooperator Team Member http://www.cooperator.com.ar Microsoft Certified Professional
