Sí, ya lo sé, es que tengo un problemita para expresarme.... :-)
2008/6/24 Daniel Calvin <[EMAIL PROTECTED]>:
> Nooo, tu wrapper no va a cambiar. Si cambias de framework de IoC cambia la
> implementación del Wrapper, solo tocas el wrapper, no la factory.
>
> Saludos
>
> Daniel
>
> El día 24 de junio de 2008 8:44, Leonardo Micheloni
> <[EMAIL PROTECTED]> escribió:
>>
>> 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
>>
>
>
>
> --
> 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/
