Relaciones entre objetos

> **
>
>
> Hola Gente:
>
> Más de una vez desde el mundo Smalltalk tiramos frases como "no, lo que
> pasa es que con objetos no necesitás caer en las relaciones como se manejan
> en el mundo de las db relacionales".
>
> Mi propia experiencia ha sido que muchas veces SI se necesita establecer
> ese tipo de relaciones (algo que el viejo framework Mewa de A Lienhard
> hacía bastante bien).
>
> Entonces la pregunta o la charla que intento motivar con este mail es como
> manejan uds las relaciones, por ejemplo si ponemos un ejemplo muy común
> tipo ciudad - departamento - provincia - pais (y no estoy ahondando en
> relaciones más complejas).
>
> Pero cada ciudad perteneces a 1 departamento, cada departamento a 1
> provincia, cada provincia a 1 pais, y al reves cada departamento tiene
> muchas ciudades, cada provincia muchos departamentos y cada país muchas
> provincias.
>
> Quizás el ejemplo es simple, pero aparece en muchos sistemas, así que me
> pareció interesante tirar la discusión acá y ver como cada uno resuelve
> este tipo de cosas, con qué patrones, etc.
>
> SAludos!
>
>
> --
> ============================================
> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
> Arduino Software  http://www.arduinosoftware.com
> PasswordsPro  http://www.passwordspro.com
> greensecure.blogspot.com germanarduino.blogspot.com
> ============================================
>
>  
>

> **
>
>
> Hola Germán,
> te cuento un poquito, nosotros en nuestro caso modelamos las relaciones de
> dos maneras posibles, dependiendo del caso puntual.
> El primero es el típico caso que maneja cualquier ORM mas o menos serio en
> el cual tenemos nuestras propias clases de colecciones que persisten en la
> base de datos. De esta manera, tenemos mappings que modelan la forma en que
> persisten en BD nuestras colecciones. En el ejemplo concreto que vos ponés,
> un país tiene provincias y la provincia conoce a su país, por lo tanto, en
> el initialize de Pais pondría:
>
> initialize
>
> super initialize.
> provincias := ORPListModel new
>
>
> Esta colección representa la relación uno a muchos mientras
> que ORPRelationsListModel modela una relación muchos a muchos.
> Porsupuesto que esta clase (que hereda de ListModel) sabe todo lo que
> tiene que hacer ya sea en la familia de los #add: como en la familia de los
> #remove:, etc.
> Luego, en algún lugar donde se define la metadata de la clase Pais, se
> agrega el mapping mas o menos de esta manera:
>
> <code>
> ...
> addMapping: (((ORPOneToManyMapping new
>  name: 'provincias';
> setOwnerBlock: [:owner :child | child pais: owner];
> elementsInitializationStrategy: ORPListModelLazyInitialization new;
>  searchPolicy: EqualitySearchPolicy new;
> elementsClass: Provincia;
> elementsClassMappingsNames: #('pais');
>  joinMappingsNames: #('id');
>                                                 cascadesOnUnstore: true;
>
> yourself);
> ...
> </code>
>
> Con eso ya estamos listos para trabajar con nuestro modelo de objetos
> teniendo un doble conocimiento si se quiere o solamente simple (es decir,
> el país conoce las provincias y ya).
> Si después en algún lugar del código hacés:
>
> miPais provincias add: (Provincia named: 'Santa Fé').
> miPais orpStore
>
> ya se guardó país con su nueva provincia relacionada.
>
>

> Eso es por un lado, por otro lado, nos alejamos un poco del modelo
> relacional y modelamos directamente la relación, ya que es necesario porque
> en nuestro dominio los objetos pueden cambiar en el tiempo sus relaciones y
> es necesario llevar una trazabilidad de esto. Es decir, una provincia es
> muy raro que se vaya a salir de un País y entrar en otro (al menos lejos de
> los imperios colonizadores es difícil que pase :P). Pero en nuestro caso
> hay mucho de este comportamiento, entonces modelamos EntityRelation y
> EntityRelationType (guiados por AOM http://adaptiveobjectmodel.com/). Una
> EntityRelationType define el tipo de relación, por ejemplo, se puede crear
> un nuevo tipo de relación de esta manera:
>
> (EntityRelationType newInstanceNamed: 'Vendedores por Zonas' childClass:
> Vendedor parentClass: Zona)
> fixedRelation: false;
>  required: true;
> cardinality: ManyToManyRelation new;
> orpStore
>
>
> Luego, con este código podés asignar un vender a una zona en una fecha
> dada:
>
> (EntityRelationType withName: 'Vendedores por Zonas' ) new "si, entienden
> new"
>     child: Vendedor withName: 'Juan';
>     owner: Zona withName: 'Oeste';
>     date: Date today;
>     orpStore
>
> De esa manera tenés al vendedor Juan relacionado a la Zona Oeste a partir
> del día de hoy, obviamente que podés asignar muchos vendedores a muchas
> zonas, desasignarlos, etc.
>
> El segundo ejemplo que te dí garpa mucho cuando tenés ese tipo de dominio
> donde las cosas se mueven en el tiempo, y necesitás trazabilidad, aunque
> también sirve para relaciones fijas que nunca van a cambiar aunque en ese
> caso pagás el costo de no tener las FK en las tablas clásicas de un modelo
> relacional.
>
>

> Salud!
> Guillermo
>
>
>
>
>
>
> El 4 de noviembre de 2012 10:06, Germán Arduino <[hidden email]>escribió:
>
> **
>>
>>
>> Hola Gente:
>>
>> Más de una vez desde el mundo Smalltalk tiramos frases como "no, lo que
>> pasa es que con objetos no necesitás caer en las relaciones como se manejan
>> en el mundo de las db relacionales".
>>
>> Mi propia experiencia ha sido que muchas veces SI se necesita establecer
>> ese tipo de relaciones (algo que el viejo framework Mewa de A Lienhard
>> hacía bastante bien).
>>
>> Entonces la pregunta o la charla que intento motivar con este mail es
>> como manejan uds las relaciones, por ejemplo si ponemos un ejemplo muy
>> común tipo ciudad - departamento - provincia - pais (y no estoy ahondando
>> en relaciones más complejas).
>>
>> Pero cada ciudad perteneces a 1 departamento, cada departamento a 1
>> provincia, cada provincia a 1 pais, y al reves cada departamento tiene
>> muchas ciudades, cada provincia muchos departamentos y cada país muchas
>> provincias.
>>
>> Quizás el ejemplo es simple, pero aparece en muchos sistemas, así que me
>> pareció interesante tirar la discusión acá y ver como cada uno resuelve
>> este tipo de cosas, con qué patrones, etc.
>>
>> SAludos!
>>
>>
>> --
>> ============================================
>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>> Arduino Software  http://www.arduinosoftware.com
>> PasswordsPro  http://www.passwordspro.com
>> greensecure.blogspot.com germanarduino.blogspot.com
>> ============================================
>>
>>
>  
>

> **
>
>
> Hola Guillermo, gracias por la respuesta, te intercalo algunos comentarios:
>
> El 7 de noviembre de 2012 11:22, Guillermo Sapaya <[hidden email]>escribió:
>
>  **
>>
>>
>> Hola Germán,
>> te cuento un poquito, nosotros en nuestro caso modelamos las relaciones
>> de dos maneras posibles, dependiendo del caso puntual.
>> El primero es el típico caso que maneja cualquier ORM mas o menos serio
>> en el cual tenemos nuestras propias clases de colecciones que persisten en
>> la base de datos. De esta manera, tenemos mappings que modelan la forma en
>> que persisten en BD nuestras colecciones. En el ejemplo concreto que vos
>> ponés, un país tiene provincias y la provincia conoce a su país, por lo
>> tanto, en el initialize de Pais pondría:
>>
>> initialize
>>
>> super initialize.
>> provincias := ORPListModel new
>>
>>
>> Esta colección representa la relación uno a muchos mientras
>> que ORPRelationsListModel modela una relación muchos a muchos.
>> Porsupuesto que esta clase (que hereda de ListModel) sabe todo lo que
>> tiene que hacer ya sea en la familia de los #add: como en la familia de los
>> #remove:, etc.
>> Luego, en algún lugar donde se define la metadata de la clase Pais, se
>> agrega el mapping mas o menos de esta manera:
>>
>> <code>
>> ...
>> addMapping: (((ORPOneToManyMapping new
>>  name: 'provincias';
>> setOwnerBlock: [:owner :child | child pais: owner];
>> elementsInitializationStrategy: ORPListModelLazyInitialization new;
>>  searchPolicy: EqualitySearchPolicy new;
>> elementsClass: Provincia;
>> elementsClassMappingsNames: #('pais');
>>  joinMappingsNames: #('id');
>>                                                 cascadesOnUnstore: true;
>>
>> yourself);
>> ...
>> </code>
>>
>> Con eso ya estamos listos para trabajar con nuestro modelo de objetos
>> teniendo un doble conocimiento si se quiere o solamente simple (es decir,
>> el país conoce las provincias y ya).
>> Si después en algún lugar del código hacés:
>>
>> miPais provincias add: (Provincia named: 'Santa Fé').
>> miPais orpStore
>>
>> ya se guardó país con su nueva provincia relacionada.
>>
>>
> Claro, entiendo esto usando Dolphin y persistiendo en una db relacional.
>
>
>
>> Eso es por un lado, por otro lado, nos alejamos un poco del modelo
>> relacional y modelamos directamente la relación, ya que es necesario porque
>> en nuestro dominio los objetos pueden cambiar en el tiempo sus relaciones y
>> es necesario llevar una trazabilidad de esto. Es decir, una provincia es
>> muy raro que se vaya a salir de un País y entrar en otro (al menos lejos de
>> los imperios colonizadores es difícil que pase :P). Pero en nuestro caso
>> hay mucho de este comportamiento, entonces modelamos EntityRelation y
>> EntityRelationType (guiados por AOM http://adaptiveobjectmodel.com/).
>> Una EntityRelationType define el tipo de relación, por ejemplo, se puede
>> crear un nuevo tipo de relación de esta manera:
>>
>> (EntityRelationType newInstanceNamed: 'Vendedores por Zonas' childClass:
>> Vendedor parentClass: Zona)
>> fixedRelation: false;
>>  required: true;
>> cardinality: ManyToManyRelation new;
>> orpStore
>>
>>
>> Luego, con este código podés asignar un vender a una zona en una fecha
>> dada:
>>
>> (EntityRelationType withName: 'Vendedores por Zonas' ) new "si, entienden
>> new"
>>     child: Vendedor withName: 'Juan';
>>     owner: Zona withName: 'Oeste';
>>     date: Date today;
>>     orpStore
>>
>> De esa manera tenés al vendedor Juan relacionado a la Zona Oeste a partir
>> del día de hoy, obviamente que podés asignar muchos vendedores a muchas
>> zonas, desasignarlos, etc.
>>
>> El segundo ejemplo que te dí garpa mucho cuando tenés ese tipo de dominio
>> donde las cosas se mueven en el tiempo, y necesitás trazabilidad, aunque
>> también sirve para relaciones fijas que nunca van a cambiar aunque en ese
>> caso pagás el costo de no tener las FK en las tablas clásicas de un modelo
>> relacional.
>>
>>
> Esto me interesa mucho más, porque prescinde de las db relacionales
> (claro, no tener las FK es un costo, pero inevitable si no usas DBs
> relacionales :) ).
>
> Cuando vos decís que usan por ejemplo "ManyToManyRelation new" esta clase
> es propia o pertenece a algunún framework? Porque también debería existir
> la OneToManyRelation por decir algo (esto vi algo en Magritte y Mewa y
> luego algo que intentamos armar nosotros, pero nunca terminó de "cerrarme"
> como quedaba físicamente luego a nivel de los objetos en si mismos,
> seguramente porque no estaba bien diseñado (si era la colección real, si
> eran referencias a la colección, etc.....)
>
>
>
>
>> Bueno, espero que se haya entendido algo, cualquier cosa no dudes en
>> preguntar!
>>
>>
>
> Gracias por compartir, saludos!
>
>
>> Salud!
>> Guillermo
>>
>>
>>
>>
>>
>>
>> El 4 de noviembre de 2012 10:06, Germán Arduino <[hidden email]>escribió:
>>
>>  **
>>>
>>>
>>> Hola Gente:
>>>
>>> Más de una vez desde el mundo Smalltalk tiramos frases como "no, lo que
>>> pasa es que con objetos no necesitás caer en las relaciones como se manejan
>>> en el mundo de las db relacionales".
>>>
>>> Mi propia experiencia ha sido que muchas veces SI se necesita establecer
>>> ese tipo de relaciones (algo que el viejo framework Mewa de A Lienhard
>>> hacía bastante bien).
>>>
>>> Entonces la pregunta o la charla que intento motivar con este mail es
>>> como manejan uds las relaciones, por ejemplo si ponemos un ejemplo muy
>>> común tipo ciudad - departamento - provincia - pais (y no estoy ahondando
>>> en relaciones más complejas).
>>>
>>> Pero cada ciudad perteneces a 1 departamento, cada departamento a 1
>>> provincia, cada provincia a 1 pais, y al reves cada departamento tiene
>>> muchas ciudades, cada provincia muchos departamentos y cada país muchas
>>> provincias.
>>>
>>> Quizás el ejemplo es simple, pero aparece en muchos sistemas, así que me
>>> pareció interesante tirar la discusión acá y ver como cada uno resuelve
>>> este tipo de cosas, con qué patrones, etc.
>>>
>>> SAludos!
>>>
>>>
>>> --
>>> ============================================
>>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>>> Arduino Software  http://www.arduinosoftware.com
>>> PasswordsPro  http://www.passwordspro.com
>>> greensecure.blogspot.com germanarduino.blogspot.com
>>> ============================================
>>>
>>>
>>
>
>
> --
> ============================================
> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
> Arduino Software  http://www.arduinosoftware.com
> PasswordsPro  http://www.passwordspro.com
> greensecure.blogspot.com germanarduino.blogspot.com
> ============================================
>
>  
>

> **
>
>
> Hola Guillermo, gracias por la respuesta, te intercalo algunos comentarios:
>
> El 7 de noviembre de 2012 11:22, Guillermo Sapaya <[hidden email]>escribió:
>
>  **
>>
>>
>> Hola Germán,
>> te cuento un poquito, nosotros en nuestro caso modelamos las relaciones
>> de dos maneras posibles, dependiendo del caso puntual.
>> El primero es el típico caso que maneja cualquier ORM mas o menos serio
>> en el cual tenemos nuestras propias clases de colecciones que persisten en
>> la base de datos. De esta manera, tenemos mappings que modelan la forma en
>> que persisten en BD nuestras colecciones. En el ejemplo concreto que vos
>> ponés, un país tiene provincias y la provincia conoce a su país, por lo
>> tanto, en el initialize de Pais pondría:
>>
>> initialize
>>
>> super initialize.
>> provincias := ORPListModel new
>>
>>
>> Esta colección representa la relación uno a muchos mientras
>> que ORPRelationsListModel modela una relación muchos a muchos.
>> Porsupuesto que esta clase (que hereda de ListModel) sabe todo lo que
>> tiene que hacer ya sea en la familia de los #add: como en la familia de los
>> #remove:, etc.
>> Luego, en algún lugar donde se define la metadata de la clase Pais, se
>> agrega el mapping mas o menos de esta manera:
>>
>> <code>
>> ...
>> addMapping: (((ORPOneToManyMapping new
>>  name: 'provincias';
>> setOwnerBlock: [:owner :child | child pais: owner];
>> elementsInitializationStrategy: ORPListModelLazyInitialization new;
>>  searchPolicy: EqualitySearchPolicy new;
>> elementsClass: Provincia;
>> elementsClassMappingsNames: #('pais');
>>  joinMappingsNames: #('id');
>>                                                 cascadesOnUnstore: true;
>>
>> yourself);
>> ...
>> </code>
>>
>> Con eso ya estamos listos para trabajar con nuestro modelo de objetos
>> teniendo un doble conocimiento si se quiere o solamente simple (es decir,
>> el país conoce las provincias y ya).
>> Si después en algún lugar del código hacés:
>>
>> miPais provincias add: (Provincia named: 'Santa Fé').
>> miPais orpStore
>>
>> ya se guardó país con su nueva provincia relacionada.
>>
>>
> Claro, entiendo esto usando Dolphin y persistiendo en una db relacional.
>
>
>
>> Eso es por un lado, por otro lado, nos alejamos un poco del modelo
>> relacional y modelamos directamente la relación, ya que es necesario porque
>> en nuestro dominio los objetos pueden cambiar en el tiempo sus relaciones y
>> es necesario llevar una trazabilidad de esto. Es decir, una provincia es
>> muy raro que se vaya a salir de un País y entrar en otro (al menos lejos de
>> los imperios colonizadores es difícil que pase :P). Pero en nuestro caso
>> hay mucho de este comportamiento, entonces modelamos EntityRelation y
>> EntityRelationType (guiados por AOM http://adaptiveobjectmodel.com/).
>> Una EntityRelationType define el tipo de relación, por ejemplo, se puede
>> crear un nuevo tipo de relación de esta manera:
>>
>> (EntityRelationType newInstanceNamed: 'Vendedores por Zonas' childClass:
>> Vendedor parentClass: Zona)
>> fixedRelation: false;
>>  required: true;
>> cardinality: ManyToManyRelation new;
>> orpStore
>>
>>
>> Luego, con este código podés asignar un vender a una zona en una fecha
>> dada:
>>
>> (EntityRelationType withName: 'Vendedores por Zonas' ) new "si, entienden
>> new"
>>     child: Vendedor withName: 'Juan';
>>     owner: Zona withName: 'Oeste';
>>     date: Date today;
>>     orpStore
>>
>> De esa manera tenés al vendedor Juan relacionado a la Zona Oeste a partir
>> del día de hoy, obviamente que podés asignar muchos vendedores a muchas
>> zonas, desasignarlos, etc.
>>
>> El segundo ejemplo que te dí garpa mucho cuando tenés ese tipo de dominio
>> donde las cosas se mueven en el tiempo, y necesitás trazabilidad, aunque
>> también sirve para relaciones fijas que nunca van a cambiar aunque en ese
>> caso pagás el costo de no tener las FK en las tablas clásicas de un modelo
>> relacional.
>>
>>
> Esto me interesa mucho más, porque prescinde de las db relacionales
> (claro, no tener las FK es un costo, pero inevitable si no usas DBs
> relacionales :) ).
>
> Cuando vos decís que usan por ejemplo "ManyToManyRelation new" esta clase
> es propia o pertenece a algunún framework? Porque también debería existir
> la OneToManyRelation por decir algo (esto vi algo en Magritte y Mewa y
> luego algo que intentamos armar nosotros, pero nunca terminó de "cerrarme"
> como quedaba físicamente luego a nivel de los objetos en si mismos,
> seguramente porque no estaba bien diseñado (si era la colección real, si
> eran referencias a la colección, etc.....)
>
>
>
>
>> Bueno, espero que se haya entendido algo, cualquier cosa no dudes en
>> preguntar!
>>
>>
>
> Gracias por compartir, saludos!
>
>
>> Salud!
>> Guillermo
>>
>>
>>
>>
>>
>>
>> El 4 de noviembre de 2012 10:06, Germán Arduino <[hidden email]>escribió:
>>
>>  **
>>>
>>>
>>> Hola Gente:
>>>
>>> Más de una vez desde el mundo Smalltalk tiramos frases como "no, lo que
>>> pasa es que con objetos no necesitás caer en las relaciones como se manejan
>>> en el mundo de las db relacionales".
>>>
>>> Mi propia experiencia ha sido que muchas veces SI se necesita establecer
>>> ese tipo de relaciones (algo que el viejo framework Mewa de A Lienhard
>>> hacía bastante bien).
>>>
>>> Entonces la pregunta o la charla que intento motivar con este mail es
>>> como manejan uds las relaciones, por ejemplo si ponemos un ejemplo muy
>>> común tipo ciudad - departamento - provincia - pais (y no estoy ahondando
>>> en relaciones más complejas).
>>>
>>> Pero cada ciudad perteneces a 1 departamento, cada departamento a 1
>>> provincia, cada provincia a 1 pais, y al reves cada departamento tiene
>>> muchas ciudades, cada provincia muchos departamentos y cada país muchas
>>> provincias.
>>>
>>> Quizás el ejemplo es simple, pero aparece en muchos sistemas, así que me
>>> pareció interesante tirar la discusión acá y ver como cada uno resuelve
>>> este tipo de cosas, con qué patrones, etc.
>>>
>>> SAludos!
>>>
>>>
>>> --
>>> ============================================
>>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>>> Arduino Software  http://www.arduinosoftware.com
>>> PasswordsPro  http://www.passwordspro.com
>>> greensecure.blogspot.com germanarduino.blogspot.com
>>> ============================================
>>>
>>>
>>
>
>
> --
> ============================================
> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
> Arduino Software  http://www.arduinosoftware.com
> PasswordsPro  http://www.passwordspro.com
> greensecure.blogspot.com germanarduino.blogspot.com
> ============================================
>
>  
>

> **
>
>
> Bueno vamos por parte,
>
> Una gran diferencia de las relaciones entre objetos y las relaciones en el
> mundo relaciones, es que las relaciones en el mundo de los objeto
> son débiles y en el relacional son  fuerte..desarrollo.
>
> Cuando en el mundo relaciones 2 entidades están relacionas existe una
> dependencia para la existencia propia entre ella  (siempre que se respete
> el ACID), una provincia no puede vivir sin país.(ponele que definimos una
> FK y las relaciones estén en BCNF) y la clave candidata de provincia
> incluya país. En el mundo relacional las tuplas no tienen existencia e
> identidad propia sino a través de sus atributos.
>
> en el mundo de los objecto estas relaciones no son parte del ambiente (ni
> el paradigma) y lo que existe mas es una colaboración entre objetos. un
> objeto tiene identidad y existencia en si mismo, mas allá de sus
> propiedades. No hay nada en el paradigma y los ambientes que se expresen
> las constrains mas allá de los que codifiques. Es mas mira lo loco que si
> tu diseño es bueno la tendencia debería ser que la relaciones
> sean polimorfisco  por lo cual la relación debería soporta no solo pais
> provincia, sino tambien pais.. territorio.. por ejemplo..
>
>
> los ORM son el puente entre estos mundos y bueno siempre una perdida en
> todo esto :).
>
> btw (ManyToManyRelation es glorp no?).
>
> la relación 1 a muchos es facil  el objeto conoce una colección de sus
> colaboradores
> la relación  muchos a 1 los muchos tiene una propiedad que referencia a 1
>
> muchos a muchos la suma de los 2. es correcto.. ummm no se.. a mi me
> funca.. el hecho que no exita un algebra de objetos como existe el algebra
> relacional me deja hacer cagadas (o no ), si ponerme colorado.
>
> Saludos
>
>
>
> http://about.me/diogenes.moreira
>
>
>
> El 8 de noviembre de 2012 08:03, Germán Arduino <[hidden email]>escribió:
>
> **
>>
>>
>> Hola Guillermo, gracias por la respuesta, te intercalo algunos
>> comentarios:
>>
>> El 7 de noviembre de 2012 11:22, Guillermo Sapaya <[hidden email]>escribió:
>>
>>  **
>>>
>>>
>>> Hola Germán,
>>> te cuento un poquito, nosotros en nuestro caso modelamos las relaciones
>>> de dos maneras posibles, dependiendo del caso puntual.
>>> El primero es el típico caso que maneja cualquier ORM mas o menos serio
>>> en el cual tenemos nuestras propias clases de colecciones que persisten en
>>> la base de datos. De esta manera, tenemos mappings que modelan la forma en
>>> que persisten en BD nuestras colecciones. En el ejemplo concreto que vos
>>> ponés, un país tiene provincias y la provincia conoce a su país, por lo
>>> tanto, en el initialize de Pais pondría:
>>>
>>> initialize
>>>
>>> super initialize.
>>> provincias := ORPListModel new
>>>
>>>
>>> Esta colección representa la relación uno a muchos mientras
>>> que ORPRelationsListModel modela una relación muchos a muchos.
>>> Porsupuesto que esta clase (que hereda de ListModel) sabe todo lo que
>>> tiene que hacer ya sea en la familia de los #add: como en la familia de los
>>> #remove:, etc.
>>> Luego, en algún lugar donde se define la metadata de la clase Pais, se
>>> agrega el mapping mas o menos de esta manera:
>>>
>>> <code>
>>> ...
>>> addMapping: (((ORPOneToManyMapping new
>>>  name: 'provincias';
>>> setOwnerBlock: [:owner :child | child pais: owner];
>>> elementsInitializationStrategy: ORPListModelLazyInitialization new;
>>>  searchPolicy: EqualitySearchPolicy new;
>>> elementsClass: Provincia;
>>> elementsClassMappingsNames: #('pais');
>>>  joinMappingsNames: #('id');
>>>                                                 cascadesOnUnstore:
>>> true;
>>> yourself);
>>> ...
>>> </code>
>>>
>>> Con eso ya estamos listos para trabajar con nuestro modelo de objetos
>>> teniendo un doble conocimiento si se quiere o solamente simple (es decir,
>>> el país conoce las provincias y ya).
>>> Si después en algún lugar del código hacés:
>>>
>>> miPais provincias add: (Provincia named: 'Santa Fé').
>>> miPais orpStore
>>>
>>> ya se guardó país con su nueva provincia relacionada.
>>>
>>>
>> Claro, entiendo esto usando Dolphin y persistiendo en una db relacional.
>>
>>
>>
>>> Eso es por un lado, por otro lado, nos alejamos un poco del modelo
>>> relacional y modelamos directamente la relación, ya que es necesario porque
>>> en nuestro dominio los objetos pueden cambiar en el tiempo sus relaciones y
>>> es necesario llevar una trazabilidad de esto. Es decir, una provincia es
>>> muy raro que se vaya a salir de un País y entrar en otro (al menos lejos de
>>> los imperios colonizadores es difícil que pase :P). Pero en nuestro caso
>>> hay mucho de este comportamiento, entonces modelamos EntityRelation y
>>> EntityRelationType (guiados por AOM http://adaptiveobjectmodel.com/).
>>> Una EntityRelationType define el tipo de relación, por ejemplo, se puede
>>> crear un nuevo tipo de relación de esta manera:
>>>
>>> (EntityRelationType newInstanceNamed: 'Vendedores por Zonas' childClass:
>>> Vendedor parentClass: Zona)
>>> fixedRelation: false;
>>>  required: true;
>>> cardinality: ManyToManyRelation new;
>>> orpStore
>>>
>>>
>>> Luego, con este código podés asignar un vender a una zona en una fecha
>>> dada:
>>>
>>> (EntityRelationType withName: 'Vendedores por Zonas' ) new "si,
>>> entienden new"
>>>     child: Vendedor withName: 'Juan';
>>>     owner: Zona withName: 'Oeste';
>>>     date: Date today;
>>>     orpStore
>>>
>>> De esa manera tenés al vendedor Juan relacionado a la Zona Oeste a
>>> partir del día de hoy, obviamente que podés asignar muchos vendedores a
>>> muchas zonas, desasignarlos, etc.
>>>
>>> El segundo ejemplo que te dí garpa mucho cuando tenés ese tipo de
>>> dominio donde las cosas se mueven en el tiempo, y necesitás trazabilidad,
>>> aunque también sirve para relaciones fijas que nunca van a cambiar aunque
>>> en ese caso pagás el costo de no tener las FK en las tablas clásicas de un
>>> modelo relacional.
>>>
>>>
>> Esto me interesa mucho más, porque prescinde de las db relacionales
>> (claro, no tener las FK es un costo, pero inevitable si no usas DBs
>> relacionales :) ).
>>
>> Cuando vos decís que usan por ejemplo "ManyToManyRelation new" esta clase
>> es propia o pertenece a algunún framework? Porque también debería existir
>> la OneToManyRelation por decir algo (esto vi algo en Magritte y Mewa y
>> luego algo que intentamos armar nosotros, pero nunca terminó de "cerrarme"
>> como quedaba físicamente luego a nivel de los objetos en si mismos,
>> seguramente porque no estaba bien diseñado (si era la colección real, si
>> eran referencias a la colección, etc.....)
>>
>>
>>
>>
>>> Bueno, espero que se haya entendido algo, cualquier cosa no dudes en
>>> preguntar!
>>>
>>>
>>
>> Gracias por compartir, saludos!
>>
>>
>>> Salud!
>>> Guillermo
>>>
>>>
>>>
>>>
>>>
>>>
>>> El 4 de noviembre de 2012 10:06, Germán Arduino <[hidden email]>escribió:
>>>
>>>  **
>>>>
>>>>
>>>> Hola Gente:
>>>>
>>>> Más de una vez desde el mundo Smalltalk tiramos frases como "no, lo que
>>>> pasa es que con objetos no necesitás caer en las relaciones como se manejan
>>>> en el mundo de las db relacionales".
>>>>
>>>> Mi propia experiencia ha sido que muchas veces SI se necesita
>>>> establecer ese tipo de relaciones (algo que el viejo framework Mewa de A
>>>> Lienhard hacía bastante bien).
>>>>
>>>> Entonces la pregunta o la charla que intento motivar con este mail es
>>>> como manejan uds las relaciones, por ejemplo si ponemos un ejemplo muy
>>>> común tipo ciudad - departamento - provincia - pais (y no estoy ahondando
>>>> en relaciones más complejas).
>>>>
>>>> Pero cada ciudad perteneces a 1 departamento, cada departamento a 1
>>>> provincia, cada provincia a 1 pais, y al reves cada departamento tiene
>>>> muchas ciudades, cada provincia muchos departamentos y cada país muchas
>>>> provincias.
>>>>
>>>> Quizás el ejemplo es simple, pero aparece en muchos sistemas, así que
>>>> me pareció interesante tirar la discusión acá y ver como cada uno resuelve
>>>> este tipo de cosas, con qué patrones, etc.
>>>>
>>>> SAludos!
>>>>
>>>>
>>>> --
>>>> ============================================
>>>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>>>> Arduino Software  http://www.arduinosoftware.com
>>>> PasswordsPro  http://www.passwordspro.com
>>>> greensecure.blogspot.com germanarduino.blogspot.com
>>>> ============================================
>>>>
>>>>
>>>
>>
>>
>> --
>> ============================================
>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>> Arduino Software  http://www.arduinosoftware.com
>> PasswordsPro  http://www.passwordspro.com
>> greensecure.blogspot.com germanarduino.blogspot.com
>> ============================================
>>
>>
>  
>

> **
>
>
> Hola Germán,
> che, no se porque pero yo había entendido que tu pregunta apuntaba a cómo
> se manejaban las relaciones entre objetos contra una relacional, por eso me
> despaché con los dos ejemplos y apunté mi respuesta a como se mapea. Sorry
> si esa no era la idea :)
> En cuanto al ManyToManyRelation es una clase nuestra, todo lo que te
> mostré con ejemplos son clases pertenecientes a frameworks hechos 100% en
> casa. Igualmente, es muy probable que hayan otros frameworks que tengan una
> clase con ese nombre, no es muy difícil, je. De hecho cuando hicimos
> nuestro ORM nos basamos en muchas cosas de Glorp, TopLink y Hibernate entre
> otros.
> Con el segundo ejemplo, te mostré solamente dos clases pero tiene un mundo
> de cosillas mas como por ejemplo:
>
> - Una registry de relaciones para realizar los lookups mas óptimos
> posibles (tené en cuenta que si hay muchos movimientos de entidades entre
> fechas, la historia se hace grande).
> - Un broker específico para los retrievals desde el almacenamiento (en
> nuestro caso una relacional y todas las relaciones persisten en una sola
> tabla, pero podría estar tranquilamente en otro medio).
> - Posibilidad de definición de jerarquías de entidades mediante los
> usuarios (EntitiesHierarchy) para permitir búsquedas en forma de árboles,
> establecer un orden de peso, etc.
>
> Al Framework lo denominamos DynER (Dynamic Entities Relationship) y lo mas
> "jugoso" que se logró con el mismo es que a cualquier entidad de nuestro
> dominio se le pueda pedir las entidades relacionadas de cualquier otra
> clase. Por ejemplo, en tu caso podrías enviarle el mismo mensaje a Pais y a
> Provincia para obtener los deparatamentos, u otras cosas por el estilo, por
> ejemplo:
>
>  "Obtener todas las provincias relacionadas con el país Argentina a la
> fecha actual"
> (Pais withName: 'Argentina') entitiesOf: Provincia currentAt: Date today
>
>  "Obtener el país al que pertenece la provincia Santa Fé a la fecha actual"
> (Provincia withName: 'Santa Fé') entityOf: Pais currentAt: Date today
>
>  "Obtener todas las provincias que se encontraron en el país Argentina
> entre el 01/01/1901 y 31/12/2000"
> (Pais withName: 'Argentina') entitiesOf: Provincia from: '01/01/1901'
> asDate to: '31/12/2000' asDate
>
>  "Obtener todos los departamentos relacionados con el país Argentina a la
> fecha actual"
> (Pais withName: 'Argentina') entitiesOf: Departamento currentAt: Date today
>
>  "Obtener todos los departamentos relacionados con la provincia Santa Fé a
> la fecha actual"
> (Provincia withName: 'Santa Fé') entitiesOf: Departamento currentAt: Date
> today
>
>  "Obtener todos los países en los que estuvo el Departamento
> Sunchales entre el 01/01/1901 y 31/12/2000. Nótese que mas allá de que sea
> una relación 1 a n, se soporta el mimso protocolo"
> (Departamento withName: 'Sunchales') entitiesOf: Pais from: '01/01/1901'
> asDate to: '31/12/2000' asDate
>
>
> Como verás, siempre los mensajes son los mismos y todas las entidades del
> dominio pueden devolver dinámicamente sus entidades relacionadas sin
> necesidad de implementar ningún método específico (es decir, nunca nos hace
> falta implementar #provincias, #departamentos, #pais, etc.).
> En nuestro caso logramos hacer funcionar todas las relaciones de nuestro
> dominio enteramente con este framework y lo mas interesante está al momento
> en que aparecen nuevas entidades con sus relaciones (o cambian las
> relaciones de las actuales entre un cliente y otro) ya que se resuelven
> configurando el sistema sin la necesidad de programar nada.
>
> Saludos,
> Guillermo
>
> El 8 de noviembre de 2012 08:03, Germán Arduino <[hidden email]>escribió:
>
>  **
>>
>>
>> Hola Guillermo, gracias por la respuesta, te intercalo algunos
>> comentarios:
>>
>> El 7 de noviembre de 2012 11:22, Guillermo Sapaya <[hidden email]>escribió:
>>
>>  **
>>>
>>>
>>> Hola Germán,
>>> te cuento un poquito, nosotros en nuestro caso modelamos las relaciones
>>> de dos maneras posibles, dependiendo del caso puntual.
>>> El primero es el típico caso que maneja cualquier ORM mas o menos serio
>>> en el cual tenemos nuestras propias clases de colecciones que persisten en
>>> la base de datos. De esta manera, tenemos mappings que modelan la forma en
>>> que persisten en BD nuestras colecciones. En el ejemplo concreto que vos
>>> ponés, un país tiene provincias y la provincia conoce a su país, por lo
>>> tanto, en el initialize de Pais pondría:
>>>
>>> initialize
>>>
>>> super initialize.
>>> provincias := ORPListModel new
>>>
>>>
>>> Esta colección representa la relación uno a muchos mientras
>>> que ORPRelationsListModel modela una relación muchos a muchos.
>>> Porsupuesto que esta clase (que hereda de ListModel) sabe todo lo que
>>> tiene que hacer ya sea en la familia de los #add: como en la familia de los
>>> #remove:, etc.
>>> Luego, en algún lugar donde se define la metadata de la clase Pais, se
>>> agrega el mapping mas o menos de esta manera:
>>>
>>> <code>
>>> ...
>>> addMapping: (((ORPOneToManyMapping new
>>>  name: 'provincias';
>>> setOwnerBlock: [:owner :child | child pais: owner];
>>> elementsInitializationStrategy: ORPListModelLazyInitialization new;
>>>  searchPolicy: EqualitySearchPolicy new;
>>> elementsClass: Provincia;
>>> elementsClassMappingsNames: #('pais');
>>>  joinMappingsNames: #('id');
>>>                                                 cascadesOnUnstore:
>>> true;
>>> yourself);
>>> ...
>>> </code>
>>>
>>> Con eso ya estamos listos para trabajar con nuestro modelo de objetos
>>> teniendo un doble conocimiento si se quiere o solamente simple (es decir,
>>> el país conoce las provincias y ya).
>>> Si después en algún lugar del código hacés:
>>>
>>> miPais provincias add: (Provincia named: 'Santa Fé').
>>> miPais orpStore
>>>
>>> ya se guardó país con su nueva provincia relacionada.
>>>
>>>
>> Claro, entiendo esto usando Dolphin y persistiendo en una db relacional.
>>
>>
>>
>>> Eso es por un lado, por otro lado, nos alejamos un poco del modelo
>>> relacional y modelamos directamente la relación, ya que es necesario porque
>>> en nuestro dominio los objetos pueden cambiar en el tiempo sus relaciones y
>>> es necesario llevar una trazabilidad de esto. Es decir, una provincia es
>>> muy raro que se vaya a salir de un País y entrar en otro (al menos lejos de
>>> los imperios colonizadores es difícil que pase :P). Pero en nuestro caso
>>> hay mucho de este comportamiento, entonces modelamos EntityRelation y
>>> EntityRelationType (guiados por AOM http://adaptiveobjectmodel.com/).
>>> Una EntityRelationType define el tipo de relación, por ejemplo, se puede
>>> crear un nuevo tipo de relación de esta manera:
>>>
>>> (EntityRelationType newInstanceNamed: 'Vendedores por Zonas' childClass:
>>> Vendedor parentClass: Zona)
>>> fixedRelation: false;
>>>  required: true;
>>> cardinality: ManyToManyRelation new;
>>> orpStore
>>>
>>>
>>> Luego, con este código podés asignar un vender a una zona en una fecha
>>> dada:
>>>
>>> (EntityRelationType withName: 'Vendedores por Zonas' ) new "si,
>>> entienden new"
>>>     child: Vendedor withName: 'Juan';
>>>     owner: Zona withName: 'Oeste';
>>>     date: Date today;
>>>     orpStore
>>>
>>> De esa manera tenés al vendedor Juan relacionado a la Zona Oeste a
>>> partir del día de hoy, obviamente que podés asignar muchos vendedores a
>>> muchas zonas, desasignarlos, etc.
>>>
>>> El segundo ejemplo que te dí garpa mucho cuando tenés ese tipo de
>>> dominio donde las cosas se mueven en el tiempo, y necesitás trazabilidad,
>>> aunque también sirve para relaciones fijas que nunca van a cambiar aunque
>>> en ese caso pagás el costo de no tener las FK en las tablas clásicas de un
>>> modelo relacional.
>>>
>>>
>> Esto me interesa mucho más, porque prescinde de las db relacionales
>> (claro, no tener las FK es un costo, pero inevitable si no usas DBs
>> relacionales :) ).
>>
>> Cuando vos decís que usan por ejemplo "ManyToManyRelation new" esta clase
>> es propia o pertenece a algunún framework? Porque también debería existir
>> la OneToManyRelation por decir algo (esto vi algo en Magritte y Mewa y
>> luego algo que intentamos armar nosotros, pero nunca terminó de "cerrarme"
>> como quedaba físicamente luego a nivel de los objetos en si mismos,
>> seguramente porque no estaba bien diseñado (si era la colección real, si
>> eran referencias a la colección, etc.....)
>>
>>
>>
>>
>>> Bueno, espero que se haya entendido algo, cualquier cosa no dudes en
>>> preguntar!
>>>
>>>
>>
>> Gracias por compartir, saludos!
>>
>>
>>>  Salud!
>>> Guillermo
>>>
>>>
>>>
>>>
>>>
>>>
>>> El 4 de noviembre de 2012 10:06, Germán Arduino <[hidden email]>escribió:
>>>
>>>  **
>>>>
>>>>
>>>> Hola Gente:
>>>>
>>>> Más de una vez desde el mundo Smalltalk tiramos frases como "no, lo que
>>>> pasa es que con objetos no necesitás caer en las relaciones como se manejan
>>>> en el mundo de las db relacionales".
>>>>
>>>> Mi propia experiencia ha sido que muchas veces SI se necesita
>>>> establecer ese tipo de relaciones (algo que el viejo framework Mewa de A
>>>> Lienhard hacía bastante bien).
>>>>
>>>> Entonces la pregunta o la charla que intento motivar con este mail es
>>>> como manejan uds las relaciones, por ejemplo si ponemos un ejemplo muy
>>>> común tipo ciudad - departamento - provincia - pais (y no estoy ahondando
>>>> en relaciones más complejas).
>>>>
>>>> Pero cada ciudad perteneces a 1 departamento, cada departamento a 1
>>>> provincia, cada provincia a 1 pais, y al reves cada departamento tiene
>>>> muchas ciudades, cada provincia muchos departamentos y cada país muchas
>>>> provincias.
>>>>
>>>> Quizás el ejemplo es simple, pero aparece en muchos sistemas, así que
>>>> me pareció interesante tirar la discusión acá y ver como cada uno resuelve
>>>> este tipo de cosas, con qué patrones, etc.
>>>>
>>>> SAludos!
>>>>
>>>>
>>>> --
>>>> ============================================
>>>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>>>> Arduino Software  http://www.arduinosoftware.com
>>>> PasswordsPro  http://www.passwordspro.com
>>>> greensecure.blogspot.com germanarduino.blogspot.com
>>>> ============================================
>>>>
>>>>
>>>
>>
>>
>> --
>> ============================================
>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>> Arduino Software  http://www.arduinosoftware.com
>> PasswordsPro  http://www.passwordspro.com
>> greensecure.blogspot.com germanarduino.blogspot.com
>> ============================================
>>
>>
>  
>

>
> Hola Guillermo:
>
> Si, a lo mejor yo no me expresé bien, quería apuntar a como modelan
> relaciones en objetos cuando NO se persiste en relacional.
>
> Igual, todo lo que comentaste es muy ilustrativo y me dispara algunas
> ideas....Siento como que en la imagen "falta algo" :)
>
> Saludos y gracias nuevamente por los ejemplos, los voy a tener muy en
> cuenta.

> **
>
>
> German:
>
> El framework que menciona Guillermo (DynER) y las clases de nuestro ORM
> que dan soporte a algunas de sus funcionalidades (como las ListModel
> persistibles) son dos cosas que en nuestro uso van de la mano, pero la idea
> principal de modelar la relación es independiente de su método de
> persistencia.
>
> En el caso nuestro, el DynER define nuevas relaciones mediante el uso de
> AOM, sin usar AOM vos podrías definir clases programáticamente, o bien las
> instancias y obtener el mismo resultado (nosotros lo tenemos asi porque las
> "clases/types" se definen por configuración, un usuario no programador, por
> asi decirlo).
>
> Volviendo a lo de las relaciones, salvo en casos muy simplistas, es muy
> util tenerlas modeladas, porque te permiten tener una trazabilidad sobre
> las mismas, cosa que pensando 100% en objetos "simples" no podrías lograr
> teniendo elementos en una collection, ya que nunca podes saber que
> elementos estuvieron antes, etc. Si la relación es parte del "dominio" de
> alguna manera debería estar modelada.
>
> En el caso nuestro, las relaciones tienen varias propiedades (como ya
> mostró Guiye) y entre ellas una de las mas determinantes es si es una
> relación fija en el tiempo, o variable.
> Esto es util en particular para los editores, ya que subyacentemente la
> relación es la misma, pero en el caso de una relación fija el editor del
> objeto (que se crea dinámicamente en base a metadatos) para la relación
> fija utilizará un combobox o similar, mientras que las relaciones dinámicas
> deben administrarse mediante otra interfaz (ya que ademas debe manejar
> historia, etc.).
>
> Adicionalmente, el framework de relaciones permite hacer el lookup
> automático entre dos entidades que no tienen una relación directa definida.
>
> Por ej, tenes una relación Persona->Localidad, y otra relación
> Localidad->GrupoGeografico. Si a aPersona le pedis su grupo a una fecha
> determinada, el framework va a tratar de encontrar "un camino" para
> resolver la solicitud, buscar el grupo correspondiente a la fecha (puede
> que la persona haya cambiado de localidad o la localidad de grupo, o
> ambas), y si no encuentra relación va a disparar un InexistentRelationError
> ;-)
>
> En nuestro caso todas las relaciones se almacenan en una sola tabla, con
> una columna que define el tipo. Llevar eso a objetos sería más simple,
> salvo que tengas miles de relaciones y cueste mantenerlo en memoria :)
>
> Saludos!
>
> --- En [hidden email], Germán Arduino <garduino@...>
> escribió:
>
> >
> > Hola Guillermo:
> >
> > Si, a lo mejor yo no me expresé bien, quería apuntar a como modelan
> > relaciones en objetos cuando NO se persiste en relacional.
> >
> > Igual, todo lo que comentaste es muy ilustrativo y me dispara algunas
> > ideas....Siento como que en la imagen "falta algo" :)
> >
> > Saludos y gracias nuevamente por los ejemplos, los voy a tener muy en
> > cuenta.
>
>  
>

> **
>
>
> Muy interesante Esteban, muchas gracias, me quedo pensando varias cosas
> para ver que / cómo implementar algunas de ellas, capaz sea otro "proyecto
> de verano" cc @ajolopez
>
> Saludos.
>
> El 9 de noviembre de 2012 18:05, emaringolo <[hidden email]>escribió:
>
> **
>>
>>
>> German:
>>
>> El framework que menciona Guillermo (DynER) y las clases de nuestro ORM
>> que dan soporte a algunas de sus funcionalidades (como las ListModel
>> persistibles) son dos cosas que en nuestro uso van de la mano, pero la idea
>> principal de modelar la relación es independiente de su método de
>> persistencia.
>>
>> En el caso nuestro, el DynER define nuevas relaciones mediante el uso de
>> AOM, sin usar AOM vos podrías definir clases programáticamente, o bien las
>> instancias y obtener el mismo resultado (nosotros lo tenemos asi porque las
>> "clases/types" se definen por configuración, un usuario no programador, por
>> asi decirlo).
>>
>> Volviendo a lo de las relaciones, salvo en casos muy simplistas, es muy
>> util tenerlas modeladas, porque te permiten tener una trazabilidad sobre
>> las mismas, cosa que pensando 100% en objetos "simples" no podrías lograr
>> teniendo elementos en una collection, ya que nunca podes saber que
>> elementos estuvieron antes, etc. Si la relación es parte del "dominio" de
>> alguna manera debería estar modelada.
>>
>> En el caso nuestro, las relaciones tienen varias propiedades (como ya
>> mostró Guiye) y entre ellas una de las mas determinantes es si es una
>> relación fija en el tiempo, o variable.
>> Esto es util en particular para los editores, ya que subyacentemente la
>> relación es la misma, pero en el caso de una relación fija el editor del
>> objeto (que se crea dinámicamente en base a metadatos) para la relación
>> fija utilizará un combobox o similar, mientras que las relaciones dinámicas
>> deben administrarse mediante otra interfaz (ya que ademas debe manejar
>> historia, etc.).
>>
>> Adicionalmente, el framework de relaciones permite hacer el lookup
>> automático entre dos entidades que no tienen una relación directa definida.
>>
>> Por ej, tenes una relación Persona->Localidad, y otra relación
>> Localidad->GrupoGeografico. Si a aPersona le pedis su grupo a una fecha
>> determinada, el framework va a tratar de encontrar "un camino" para
>> resolver la solicitud, buscar el grupo correspondiente a la fecha (puede
>> que la persona haya cambiado de localidad o la localidad de grupo, o
>> ambas), y si no encuentra relación va a disparar un InexistentRelationError
>> ;-)
>>
>> En nuestro caso todas las relaciones se almacenan en una sola tabla, con
>> una columna que define el tipo. Llevar eso a objetos sería más simple,
>> salvo que tengas miles de relaciones y cueste mantenerlo en memoria :)
>>
>> Saludos!
>>
>> --- En [hidden email], Germán Arduino <garduino@...>
>> escribió:
>>
>> >
>> > Hola Guillermo:
>> >
>> > Si, a lo mejor yo no me expresé bien, quería apuntar a como modelan
>> > relaciones en objetos cuando NO se persiste en relacional.
>> >
>> > Igual, todo lo que comentaste es muy ilustrativo y me dispara algunas
>> > ideas....Siento como que en la imagen "falta algo" :)
>> >
>> > Saludos y gracias nuevamente por los ejemplos, los voy a tener muy en
>> > cuenta.
>>
>>
>
>
> --
> ============================================
> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
> Arduino Software  http://www.arduinosoftware.com
> PasswordsPro  http://www.passwordspro.com
> greensecure.blogspot.com germanarduino.blogspot.com
> ============================================
>
>  
>

> **
>
>
> Jajaja! Gracias @garduino por cc a mi ;-)
>
> Aporto algo corto: uds tienen select: sobre una coleccion que recuerde. En
> .NET tenemos Linq, que permite seleccionar tanto sobre objetos en memoria,
> como sobre objetos mapeados desde una base relacional. Eso lo consigue
> porque la forma de programar (de hacer el select: de uds) es la misma, pero
> por abajo, hay un Linq Provider para memoria, y un Linq Provider para SQL.
> Y con un poco de cuidado, muchas veces en equipos agiles, programamos "todo
> en memoria" y solo en iteraciones avanzadas pasamos a tenerlo en una base
> relacional. En el proyecto de esta semana, ya van 15 iteraciones con
> "modelo de dominio en memoria" y todo pipi cucu ;-)
>
> Una de las motivaciones para meterme a jugar con VMs de Smalltalk caseras,
> es jugar con esos temas: poder tener, por ejemplo, objetos en memoria o
> distribuidos o congelados/descongelados en una base de objetos, pero a
> nivel VM, en vez de a nivel mas arriba: que el programador no tenga que
> "hamacarse" mucho para conseguir esos temas. Pero no se si me explico, o si
> aporta a este thread.... Algo de eso se me quedo de leer en los noventa
> alguna Dr. Dobb's donde mencionaban esos "approaches".
>
> Otro si: cuando lei a @garduino "en la imagen falta algo", me imagine eso:
> un allInstances select: optimizado, para traer todas las facturas de un
> cliente....
>
> Tiempo de cenar por aca...
>
> Nos leemos!
>
> Angel "Java" Lopez
> @ajlopez
> gh:ajlopez
>
> 2012/11/9 Germán Arduino <[hidden email]>
>
>> **
>>
>>
>> Muy interesante Esteban, muchas gracias, me quedo pensando varias cosas
>> para ver que / cómo implementar algunas de ellas, capaz sea otro "proyecto
>> de verano" cc @ajolopez
>>
>> Saludos.
>>
>> El 9 de noviembre de 2012 18:05, emaringolo <[hidden email]>escribió:
>>
>> **
>>>
>>>
>>> German:
>>>
>>> El framework que menciona Guillermo (DynER) y las clases de nuestro ORM
>>> que dan soporte a algunas de sus funcionalidades (como las ListModel
>>> persistibles) son dos cosas que en nuestro uso van de la mano, pero la idea
>>> principal de modelar la relación es independiente de su método de
>>> persistencia.
>>>
>>> En el caso nuestro, el DynER define nuevas relaciones mediante el uso de
>>> AOM, sin usar AOM vos podrías definir clases programáticamente, o bien las
>>> instancias y obtener el mismo resultado (nosotros lo tenemos asi porque las
>>> "clases/types" se definen por configuración, un usuario no programador, por
>>> asi decirlo).
>>>
>>> Volviendo a lo de las relaciones, salvo en casos muy simplistas, es muy
>>> util tenerlas modeladas, porque te permiten tener una trazabilidad sobre
>>> las mismas, cosa que pensando 100% en objetos "simples" no podrías lograr
>>> teniendo elementos en una collection, ya que nunca podes saber que
>>> elementos estuvieron antes, etc. Si la relación es parte del "dominio" de
>>> alguna manera debería estar modelada.
>>>
>>> En el caso nuestro, las relaciones tienen varias propiedades (como ya
>>> mostró Guiye) y entre ellas una de las mas determinantes es si es una
>>> relación fija en el tiempo, o variable.
>>> Esto es util en particular para los editores, ya que subyacentemente la
>>> relación es la misma, pero en el caso de una relación fija el editor del
>>> objeto (que se crea dinámicamente en base a metadatos) para la relación
>>> fija utilizará un combobox o similar, mientras que las relaciones dinámicas
>>> deben administrarse mediante otra interfaz (ya que ademas debe manejar
>>> historia, etc.).
>>>
>>> Adicionalmente, el framework de relaciones permite hacer el lookup
>>> automático entre dos entidades que no tienen una relación directa definida.
>>>
>>> Por ej, tenes una relación Persona->Localidad, y otra relación
>>> Localidad->GrupoGeografico. Si a aPersona le pedis su grupo a una fecha
>>> determinada, el framework va a tratar de encontrar "un camino" para
>>> resolver la solicitud, buscar el grupo correspondiente a la fecha (puede
>>> que la persona haya cambiado de localidad o la localidad de grupo, o
>>> ambas), y si no encuentra relación va a disparar un InexistentRelationError
>>> ;-)
>>>
>>> En nuestro caso todas las relaciones se almacenan en una sola tabla, con
>>> una columna que define el tipo. Llevar eso a objetos sería más simple,
>>> salvo que tengas miles de relaciones y cueste mantenerlo en memoria :)
>>>
>>> Saludos!
>>>
>>> --- En [hidden email], Germán Arduino <garduino@...>
>>> escribió:
>>>
>>> >
>>> > Hola Guillermo:
>>> >
>>> > Si, a lo mejor yo no me expresé bien, quería apuntar a como modelan
>>> > relaciones en objetos cuando NO se persiste en relacional.
>>> >
>>> > Igual, todo lo que comentaste es muy ilustrativo y me dispara algunas
>>> > ideas....Siento como que en la imagen "falta algo" :)
>>> >
>>> > Saludos y gracias nuevamente por los ejemplos, los voy a tener muy en
>>> > cuenta.
>>>
>>>
>>
>>
>> --
>> ============================================
>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>> Arduino Software  http://www.arduinosoftware.com
>> PasswordsPro  http://www.passwordspro.com
>> greensecure.blogspot.com germanarduino.blogspot.com
>> ============================================
>>
>>
>  
>

> Un placer, quería "convocarte" a la charla :)
>
> Lo de la imagen es tan asi, digo, la idea que tenía yo hace unos años
> (cuando tenía màs ganas de Smalltalk que ahora) era que los objetos tengan
> los métodos necesarios para proveer las relaciones (integridad
> referencial?) entre los mismos.
>
> Y hablando de bueyes perdidos y de generación de código (otro tema que me
> apasiona), en mi humilde entender, hoy los desarrolladores tendríamos que
> tener el tiempo liberado para los problemas más complejos (hace como 30
> años que escucho esta frase!). Pero viene bien como introducción para
> comentar que a lo que me refiero y a lo  que nosotros con Pato queríamos
> hacer con el SDA (para objetos) era lo que exactamente hace ScriptCase para
> PHP y BD relacionales (http://www.scriptcase.com). Ni más ni menos!
>
> Salud y buen provecho (por acá también, hoy viernes y le voy a rajar una
> pizza de ananá y a la miércoles la dieta...:) )
>
> El 9 de noviembre de 2012 20:56, Angel Java Lopez <[hidden email]>escribió:
>
>  **
>>
>>
>> Jajaja! Gracias @garduino por cc a mi ;-)
>>
>> Aporto algo corto: uds tienen select: sobre una coleccion que recuerde.
>> En .NET tenemos Linq, que permite seleccionar tanto sobre objetos en
>> memoria, como sobre objetos mapeados desde una base relacional. Eso lo
>> consigue porque la forma de programar (de hacer el select: de uds) es la
>> misma, pero por abajo, hay un Linq Provider para memoria, y un Linq
>> Provider para SQL. Y con un poco de cuidado, muchas veces en equipos
>> agiles, programamos "todo en memoria" y solo en iteraciones avanzadas
>> pasamos a tenerlo en una base relacional. En el proyecto de esta semana, ya
>> van 15 iteraciones con "modelo de dominio en memoria" y todo pipi cucu ;-)
>>
>> Una de las motivaciones para meterme a jugar con VMs de Smalltalk
>> caseras, es jugar con esos temas: poder tener, por ejemplo, objetos en
>> memoria o distribuidos o congelados/descongelados en una base de objetos,
>> pero a nivel VM, en vez de a nivel mas arriba: que el programador no tenga
>> que "hamacarse" mucho para conseguir esos temas. Pero no se si me explico,
>> o si aporta a este thread.... Algo de eso se me quedo de leer en los
>> noventa alguna Dr. Dobb's donde mencionaban esos "approaches".
>>
>> Otro si: cuando lei a @garduino "en la imagen falta algo", me imagine
>> eso: un allInstances select: optimizado, para traer todas las facturas de
>> un cliente....
>>
>> Tiempo de cenar por aca...
>>
>> Nos leemos!
>>
>> Angel "Java" Lopez
>> @ajlopez
>> gh:ajlopez
>>
>> 2012/11/9 Germán Arduino <[hidden email]>
>>
>>> **
>>>
>>>
>>> Muy interesante Esteban, muchas gracias, me quedo pensando varias cosas
>>> para ver que / cómo implementar algunas de ellas, capaz sea otro "proyecto
>>> de verano" cc @ajolopez
>>>
>>> Saludos.
>>>
>>> El 9 de noviembre de 2012 18:05, emaringolo <[hidden email]>escribió:
>>>
>>> **
>>>>
>>>>
>>>> German:
>>>>
>>>> El framework que menciona Guillermo (DynER) y las clases de nuestro ORM
>>>> que dan soporte a algunas de sus funcionalidades (como las ListModel
>>>> persistibles) son dos cosas que en nuestro uso van de la mano, pero la idea
>>>> principal de modelar la relación es independiente de su método de
>>>> persistencia.
>>>>
>>>> En el caso nuestro, el DynER define nuevas relaciones mediante el uso
>>>> de AOM, sin usar AOM vos podrías definir clases programáticamente, o bien
>>>> las instancias y obtener el mismo resultado (nosotros lo tenemos asi porque
>>>> las "clases/types" se definen por configuración, un usuario no programador,
>>>> por asi decirlo).
>>>>
>>>> Volviendo a lo de las relaciones, salvo en casos muy simplistas, es muy
>>>> util tenerlas modeladas, porque te permiten tener una trazabilidad sobre
>>>> las mismas, cosa que pensando 100% en objetos "simples" no podrías lograr
>>>> teniendo elementos en una collection, ya que nunca podes saber que
>>>> elementos estuvieron antes, etc. Si la relación es parte del "dominio" de
>>>> alguna manera debería estar modelada.
>>>>
>>>> En el caso nuestro, las relaciones tienen varias propiedades (como ya
>>>> mostró Guiye) y entre ellas una de las mas determinantes es si es una
>>>> relación fija en el tiempo, o variable.
>>>> Esto es util en particular para los editores, ya que subyacentemente la
>>>> relación es la misma, pero en el caso de una relación fija el editor del
>>>> objeto (que se crea dinámicamente en base a metadatos) para la relación
>>>> fija utilizará un combobox o similar, mientras que las relaciones dinámicas
>>>> deben administrarse mediante otra interfaz (ya que ademas debe manejar
>>>> historia, etc.).
>>>>
>>>> Adicionalmente, el framework de relaciones permite hacer el lookup
>>>> automático entre dos entidades que no tienen una relación directa definida.
>>>>
>>>> Por ej, tenes una relación Persona->Localidad, y otra relación
>>>> Localidad->GrupoGeografico. Si a aPersona le pedis su grupo a una fecha
>>>> determinada, el framework va a tratar de encontrar "un camino" para
>>>> resolver la solicitud, buscar el grupo correspondiente a la fecha (puede
>>>> que la persona haya cambiado de localidad o la localidad de grupo, o
>>>> ambas), y si no encuentra relación va a disparar un InexistentRelationError
>>>> ;-)
>>>>
>>>> En nuestro caso todas las relaciones se almacenan en una sola tabla,
>>>> con una columna que define el tipo. Llevar eso a objetos sería más simple,
>>>> salvo que tengas miles de relaciones y cueste mantenerlo en memoria :)
>>>>
>>>> Saludos!
>>>>
>>>> --- En [hidden email], Germán Arduino <garduino@...>
>>>> escribió:
>>>>
>>>> >
>>>> > Hola Guillermo:
>>>> >
>>>> > Si, a lo mejor yo no me expresé bien, quería apuntar a como modelan
>>>> > relaciones en objetos cuando NO se persiste en relacional.
>>>> >
>>>> > Igual, todo lo que comentaste es muy ilustrativo y me dispara algunas
>>>> > ideas....Siento como que en la imagen "falta algo" :)
>>>> >
>>>> > Saludos y gracias nuevamente por los ejemplos, los voy a tener muy en
>>>> > cuenta.
>>>>
>>>>
>>>
>>>
>>> --
>>> ============================================
>>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>>> Arduino Software  http://www.arduinosoftware.com
>>> PasswordsPro  http://www.passwordspro.com
>>> greensecure.blogspot.com germanarduino.blogspot.com
>>> ============================================
>>>
>>>
>>  
>>
>
>
>
> --
>

> **
>
>
> Perdón, la url es http://www.scriptcase.net (.net no .com).
>
> El 9 de noviembre de 2012 21:10, Germán Arduino <[hidden email]>escribió:
>
> Un placer, quería "convocarte" a la charla :)
>>
>> Lo de la imagen es tan asi, digo, la idea que tenía yo hace unos años
>> (cuando tenía màs ganas de Smalltalk que ahora) era que los objetos tengan
>> los métodos necesarios para proveer las relaciones (integridad
>> referencial?) entre los mismos.
>>
>> Y hablando de bueyes perdidos y de generación de código (otro tema que me
>> apasiona), en mi humilde entender, hoy los desarrolladores tendríamos que
>> tener el tiempo liberado para los problemas más complejos (hace como 30
>> años que escucho esta frase!). Pero viene bien como introducción para
>> comentar que a lo que me refiero y a lo  que nosotros con Pato queríamos
>> hacer con el SDA (para objetos) era lo que exactamente hace ScriptCase para
>> PHP y BD relacionales (http://www.scriptcase.com). Ni más ni menos!
>>
>> Salud y buen provecho (por acá también, hoy viernes y le voy a rajar una
>> pizza de ananá y a la miércoles la dieta...:) )
>>
>> El 9 de noviembre de 2012 20:56, Angel Java Lopez <[hidden email]>escribió:
>>
>>  **
>>>
>>>
>>> Jajaja! Gracias @garduino por cc a mi ;-)
>>>
>>> Aporto algo corto: uds tienen select: sobre una coleccion que recuerde.
>>> En .NET tenemos Linq, que permite seleccionar tanto sobre objetos en
>>> memoria, como sobre objetos mapeados desde una base relacional. Eso lo
>>> consigue porque la forma de programar (de hacer el select: de uds) es la
>>> misma, pero por abajo, hay un Linq Provider para memoria, y un Linq
>>> Provider para SQL. Y con un poco de cuidado, muchas veces en equipos
>>> agiles, programamos "todo en memoria" y solo en iteraciones avanzadas
>>> pasamos a tenerlo en una base relacional. En el proyecto de esta semana, ya
>>> van 15 iteraciones con "modelo de dominio en memoria" y todo pipi cucu ;-)
>>>
>>> Una de las motivaciones para meterme a jugar con VMs de Smalltalk
>>> caseras, es jugar con esos temas: poder tener, por ejemplo, objetos en
>>> memoria o distribuidos o congelados/descongelados en una base de objetos,
>>> pero a nivel VM, en vez de a nivel mas arriba: que el programador no tenga
>>> que "hamacarse" mucho para conseguir esos temas. Pero no se si me explico,
>>> o si aporta a este thread.... Algo de eso se me quedo de leer en los
>>> noventa alguna Dr. Dobb's donde mencionaban esos "approaches".
>>>
>>> Otro si: cuando lei a @garduino "en la imagen falta algo", me imagine
>>> eso: un allInstances select: optimizado, para traer todas las facturas de
>>> un cliente....
>>>
>>> Tiempo de cenar por aca...
>>>
>>> Nos leemos!
>>>
>>> Angel "Java" Lopez
>>> @ajlopez
>>> gh:ajlopez
>>>
>>> 2012/11/9 Germán Arduino <[hidden email]>
>>>
>>>> **
>>>>
>>>>
>>>> Muy interesante Esteban, muchas gracias, me quedo pensando varias cosas
>>>> para ver que / cómo implementar algunas de ellas, capaz sea otro "proyecto
>>>> de verano" cc @ajolopez
>>>>
>>>> Saludos.
>>>>
>>>> El 9 de noviembre de 2012 18:05, emaringolo <[hidden email]>escribió:
>>>>
>>>> **
>>>>>
>>>>>
>>>>> German:
>>>>>
>>>>> El framework que menciona Guillermo (DynER) y las clases de nuestro
>>>>> ORM que dan soporte a algunas de sus funcionalidades (como las ListModel
>>>>> persistibles) son dos cosas que en nuestro uso van de la mano, pero la idea
>>>>> principal de modelar la relación es independiente de su método de
>>>>> persistencia.
>>>>>
>>>>> En el caso nuestro, el DynER define nuevas relaciones mediante el uso
>>>>> de AOM, sin usar AOM vos podrías definir clases programáticamente, o bien
>>>>> las instancias y obtener el mismo resultado (nosotros lo tenemos asi porque
>>>>> las "clases/types" se definen por configuración, un usuario no programador,
>>>>> por asi decirlo).
>>>>>
>>>>> Volviendo a lo de las relaciones, salvo en casos muy simplistas, es
>>>>> muy util tenerlas modeladas, porque te permiten tener una trazabilidad
>>>>> sobre las mismas, cosa que pensando 100% en objetos "simples" no podrías
>>>>> lograr teniendo elementos en una collection, ya que nunca podes saber que
>>>>> elementos estuvieron antes, etc. Si la relación es parte del "dominio" de
>>>>> alguna manera debería estar modelada.
>>>>>
>>>>> En el caso nuestro, las relaciones tienen varias propiedades (como ya
>>>>> mostró Guiye) y entre ellas una de las mas determinantes es si es una
>>>>> relación fija en el tiempo, o variable.
>>>>> Esto es util en particular para los editores, ya que subyacentemente
>>>>> la relación es la misma, pero en el caso de una relación fija el editor del
>>>>> objeto (que se crea dinámicamente en base a metadatos) para la relación
>>>>> fija utilizará un combobox o similar, mientras que las relaciones dinámicas
>>>>> deben administrarse mediante otra interfaz (ya que ademas debe manejar
>>>>> historia, etc.).
>>>>>
>>>>> Adicionalmente, el framework de relaciones permite hacer el lookup
>>>>> automático entre dos entidades que no tienen una relación directa definida.
>>>>>
>>>>> Por ej, tenes una relación Persona->Localidad, y otra relación
>>>>> Localidad->GrupoGeografico. Si a aPersona le pedis su grupo a una fecha
>>>>> determinada, el framework va a tratar de encontrar "un camino" para
>>>>> resolver la solicitud, buscar el grupo correspondiente a la fecha (puede
>>>>> que la persona haya cambiado de localidad o la localidad de grupo, o
>>>>> ambas), y si no encuentra relación va a disparar un InexistentRelationError
>>>>> ;-)
>>>>>
>>>>> En nuestro caso todas las relaciones se almacenan en una sola tabla,
>>>>> con una columna que define el tipo. Llevar eso a objetos sería más simple,
>>>>> salvo que tengas miles de relaciones y cueste mantenerlo en memoria :)
>>>>>
>>>>> Saludos!
>>>>>
>>>>> --- En [hidden email], Germán Arduino <garduino@...>
>>>>> escribió:
>>>>>
>>>>> >
>>>>> > Hola Guillermo:
>>>>> >
>>>>> > Si, a lo mejor yo no me expresé bien, quería apuntar a como modelan
>>>>> > relaciones en objetos cuando NO se persiste en relacional.
>>>>> >
>>>>> > Igual, todo lo que comentaste es muy ilustrativo y me dispara algunas
>>>>> > ideas....Siento como que en la imagen "falta algo" :)
>>>>> >
>>>>> > Saludos y gracias nuevamente por los ejemplos, los voy a tener muy en
>>>>> > cuenta.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> ============================================
>>>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>>>> Arduino Software  http://www.arduinosoftware.com
>>>> PasswordsPro  http://www.passwordspro.com
>>>> greensecure.blogspot.com germanarduino.blogspot.com
>>>> ============================================
>>>>
>>>>
>>>
>>
>>
>> --
>>
>  
>

> **
>
>
> Hola gente!
>
> Gracias maese @garduino, interesante lo de scriptcase!
> Lo tenia en mis enlaces de http://delicious.com/ajlopez/codegeneration
> en particular en http://delicious.com/ajlopez/codegeneration+php
> pero se me habia ido del radar ;-)
>
> Ya veo de donde venia tu interes en las relaciones de objetos. Habria
> tanto que hablar y discutir de generacion de codigo (motivaciones, pros y
> contras...)  Jeje... si querias que "convocarme", jeje con lo de generacion
> de codigo lo logras ;-)
>
> Nos leemos!
>
> Angel "Java" Lopez
> @ajlopez
> gh:ajlopez
>
>
>
>
> 2012/11/9 Germán Arduino <[hidden email]>
>
>> **
>>
>>
>> Perdón, la url es http://www.scriptcase.net (.net no .com).
>>
>> El 9 de noviembre de 2012 21:10, Germán Arduino <[hidden email]>escribió:
>>
>> Un placer, quería "convocarte" a la charla :)
>>>
>>> Lo de la imagen es tan asi, digo, la idea que tenía yo hace unos años
>>> (cuando tenía màs ganas de Smalltalk que ahora) era que los objetos tengan
>>> los métodos necesarios para proveer las relaciones (integridad
>>> referencial?) entre los mismos.
>>>
>>> Y hablando de bueyes perdidos y de generación de código (otro tema que
>>> me apasiona), en mi humilde entender, hoy los desarrolladores tendríamos
>>> que tener el tiempo liberado para los problemas más complejos (hace como 30
>>> años que escucho esta frase!). Pero viene bien como introducción para
>>> comentar que a lo que me refiero y a lo  que nosotros con Pato queríamos
>>> hacer con el SDA (para objetos) era lo que exactamente hace ScriptCase para
>>> PHP y BD relacionales (http://www.scriptcase.com). Ni más ni menos!
>>>
>>> Salud y buen provecho (por acá también, hoy viernes y le voy a rajar una
>>> pizza de ananá y a la miércoles la dieta...:) )
>>>
>>> El 9 de noviembre de 2012 20:56, Angel Java Lopez <[hidden email]
>>> > escribió:
>>>
>>>  **
>>>>
>>>>
>>>> Jajaja! Gracias @garduino por cc a mi ;-)
>>>>
>>>> Aporto algo corto: uds tienen select: sobre una coleccion que recuerde.
>>>> En .NET tenemos Linq, que permite seleccionar tanto sobre objetos en
>>>> memoria, como sobre objetos mapeados desde una base relacional. Eso lo
>>>> consigue porque la forma de programar (de hacer el select: de uds) es la
>>>> misma, pero por abajo, hay un Linq Provider para memoria, y un Linq
>>>> Provider para SQL. Y con un poco de cuidado, muchas veces en equipos
>>>> agiles, programamos "todo en memoria" y solo en iteraciones avanzadas
>>>> pasamos a tenerlo en una base relacional. En el proyecto de esta semana, ya
>>>> van 15 iteraciones con "modelo de dominio en memoria" y todo pipi cucu ;-)
>>>>
>>>> Una de las motivaciones para meterme a jugar con VMs de Smalltalk
>>>> caseras, es jugar con esos temas: poder tener, por ejemplo, objetos en
>>>> memoria o distribuidos o congelados/descongelados en una base de objetos,
>>>> pero a nivel VM, en vez de a nivel mas arriba: que el programador no tenga
>>>> que "hamacarse" mucho para conseguir esos temas. Pero no se si me explico,
>>>> o si aporta a este thread.... Algo de eso se me quedo de leer en los
>>>> noventa alguna Dr. Dobb's donde mencionaban esos "approaches".
>>>>
>>>> Otro si: cuando lei a @garduino "en la imagen falta algo", me imagine
>>>> eso: un allInstances select: optimizado, para traer todas las facturas de
>>>> un cliente....
>>>>
>>>> Tiempo de cenar por aca...
>>>>
>>>> Nos leemos!
>>>>
>>>> Angel "Java" Lopez
>>>> @ajlopez
>>>> gh:ajlopez
>>>>
>>>> 2012/11/9 Germán Arduino <[hidden email]>
>>>>
>>>>> **
>>>>>
>>>>>
>>>>> Muy interesante Esteban, muchas gracias, me quedo pensando varias
>>>>> cosas para ver que / cómo implementar algunas de ellas, capaz sea otro
>>>>> "proyecto de verano" cc @ajolopez
>>>>>
>>>>> Saludos.
>>>>>
>>>>> El 9 de noviembre de 2012 18:05, emaringolo <[hidden email]>escribió:
>>>>>
>>>>> **
>>>>>>
>>>>>>
>>>>>> German:
>>>>>>
>>>>>> El framework que menciona Guillermo (DynER) y las clases de nuestro
>>>>>> ORM que dan soporte a algunas de sus funcionalidades (como las ListModel
>>>>>> persistibles) son dos cosas que en nuestro uso van de la mano, pero la idea
>>>>>> principal de modelar la relación es independiente de su método de
>>>>>> persistencia.
>>>>>>
>>>>>> En el caso nuestro, el DynER define nuevas relaciones mediante el uso
>>>>>> de AOM, sin usar AOM vos podrías definir clases programáticamente, o bien
>>>>>> las instancias y obtener el mismo resultado (nosotros lo tenemos asi porque
>>>>>> las "clases/types" se definen por configuración, un usuario no programador,
>>>>>> por asi decirlo).
>>>>>>
>>>>>> Volviendo a lo de las relaciones, salvo en casos muy simplistas, es
>>>>>> muy util tenerlas modeladas, porque te permiten tener una trazabilidad
>>>>>> sobre las mismas, cosa que pensando 100% en objetos "simples" no podrías
>>>>>> lograr teniendo elementos en una collection, ya que nunca podes saber que
>>>>>> elementos estuvieron antes, etc. Si la relación es parte del "dominio" de
>>>>>> alguna manera debería estar modelada.
>>>>>>
>>>>>> En el caso nuestro, las relaciones tienen varias propiedades (como ya
>>>>>> mostró Guiye) y entre ellas una de las mas determinantes es si es una
>>>>>> relación fija en el tiempo, o variable.
>>>>>> Esto es util en particular para los editores, ya que subyacentemente
>>>>>> la relación es la misma, pero en el caso de una relación fija el editor del
>>>>>> objeto (que se crea dinámicamente en base a metadatos) para la relación
>>>>>> fija utilizará un combobox o similar, mientras que las relaciones dinámicas
>>>>>> deben administrarse mediante otra interfaz (ya que ademas debe manejar
>>>>>> historia, etc.).
>>>>>>
>>>>>> Adicionalmente, el framework de relaciones permite hacer el lookup
>>>>>> automático entre dos entidades que no tienen una relación directa definida.
>>>>>>
>>>>>> Por ej, tenes una relación Persona->Localidad, y otra relación
>>>>>> Localidad->GrupoGeografico. Si a aPersona le pedis su grupo a una fecha
>>>>>> determinada, el framework va a tratar de encontrar "un camino" para
>>>>>> resolver la solicitud, buscar el grupo correspondiente a la fecha (puede
>>>>>> que la persona haya cambiado de localidad o la localidad de grupo, o
>>>>>> ambas), y si no encuentra relación va a disparar un InexistentRelationError
>>>>>> ;-)
>>>>>>
>>>>>> En nuestro caso todas las relaciones se almacenan en una sola tabla,
>>>>>> con una columna que define el tipo. Llevar eso a objetos sería más simple,
>>>>>> salvo que tengas miles de relaciones y cueste mantenerlo en memoria :)
>>>>>>
>>>>>> Saludos!
>>>>>>
>>>>>> --- En [hidden email], Germán Arduino <garduino@...>
>>>>>> escribió:
>>>>>>
>>>>>> >
>>>>>> > Hola Guillermo:
>>>>>> >
>>>>>> > Si, a lo mejor yo no me expresé bien, quería apuntar a como modelan
>>>>>> > relaciones en objetos cuando NO se persiste en relacional.
>>>>>> >
>>>>>> > Igual, todo lo que comentaste es muy ilustrativo y me dispara
>>>>>> algunas
>>>>>> > ideas....Siento como que en la imagen "falta algo" :)
>>>>>> >
>>>>>> > Saludos y gracias nuevamente por los ejemplos, los voy a tener muy
>>>>>> en
>>>>>> > cuenta.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ============================================
>>>>> Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
>>>>> Arduino Software  http://www.arduinosoftware.com
>>>>> PasswordsPro  http://www.passwordspro.com
>>>>> greensecure.blogspot.com germanarduino.blogspot.com
>>>>> ============================================
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>>
>>
>  
>