close Warning: Can't synchronize with repository "(default)" (/var/svn/mms does not appear to be a Subversion repository.). Look in the Trac log for more information.

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#87 closed doubt (fixed)

Independencia de los objetos principales de MMS — at Version 3

Reported by: Pedro Gea Owned by: Pedro Gea
Priority: blocker Milestone: Persistence 0.5
Component: Persistence Keywords:
Cc:

Description (last modified by Pedro Gea)

La independencia de los objetos principales de MMS: @MMS.Variable,

@MMS.Model y @MMS.Estimation es un punto importante a revisar.
Ya que no sólo afecta a la manera de trabajar con ellos sino también a
cómo plantear la persistencia.

Change History (3)

comment:1 Changed 15 years ago by Pedro Gea

Status: newaccepted

Parece coherente que los tres (por ahora) objetos principales de MMS sean
independientes, en el sentido que uno no necesite de los otros, una vez
que esté definido.
Esto sin embargo no se ha tratado de la misma manera para las relaciones
Variable-Model y Model-Estimation.

Repasemos estos conceptos:

Un modelo (@MMS.Model) posee relaciones con las variables (@MMS.Variable)
a través de las variables del modelo (@MMS.ModelVariable). En un principio
éstas contenían una referencia a las variables, de manera que impedía el
borrado de las mismas, la no existencia de estas deja cojo al modelo en
una posterior recarga del mismo, y la modificación de las variables
modificaba (por así decirlo) la definición del modelo.

Una estimación (@MMS.Estimation) posee una relación con un modelo
(@MMS.Model) a través de una referencia al modelo y/o a través de un
adaptador del modelo (@MMS.ModelAdapter). En un principio esta relación se
concibió como una copia del modelo, de manera que dejaba libertad al
modelo (del contenedor) para cambiar o incluso desaparecer sin afectar a
la estimación, no siendo la relación indirecta con las variables del mismo
tipo.

Hace falta inclinarse por una u otra opción y ser consecuentes.

  • Si optamos por la referencia (y no la copia) debemos ser conscientes de

los cambios que provocan en unos objetos el cambio de otros. Además
debemos informar a los objetos referenciados de quienes los referencian
para permitir por ejemplo su borrado.

Esta opción facilita la persistencia (sobre todo la persistencia en

base de datos) al no tener que almacenar los objetos principales en
distintos ámbitos.

  • Si optamos por la copia debemos ser conscientes que los cambios en unos

no afectan a los otros y para que esto ocurra deberíamos llamar a unos
métodos del tipo UpdateFromMMS que buscaría el objeto equivalente en el
contenedor principal de MMS y actualizaria la definición, de acuerdo a la
definición existente. También podríamos utilizar métodos del tipos
UpdateToMMS que llevaran al contenedor principal la definición local.

En este caso debemos pesar un poco mejor cómo tratar la persistencia de

los objetos definidos (copiados) en el entorno de otro objeto.

comment:2 Changed 15 years ago by Pedro Gea

Resolution: fixed
Status: acceptedclosed

La opción elegida es la segunda: la de copia. Así algunos objetos
principales son contenedores de otros.
Para facilitar la comunicación entre unos y otros hemos de desarrollar
mecanismos
de sincronización: véase el tiquet #91.

comment:3 Changed 15 years ago by Pedro Gea

Description: modified (diff)
Milestone: PersistenciaPersistence 0.5
Note: See TracTickets for help on using tickets.