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/
