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
