Fabio, entiendo que no lo entiendas, en serio, pero "mi vida
profesional ES complicada" no la complico yo, "ya viene así".
Estoy intentando exponer el porque "mi vida profesional es
complicada", seguro que cuando leas lo que estoy escribiendo me
entenderás.
En cuanto lo escriba lo posteo y paso el link.
No quiero una sola bolsa de gatos, de hecho la idea de la tabla
"Relaciones" es solo una idea, ya que, gracias a ti entre otros, ahora
no pienso en tablas, pienso en objetos.
ElementosRelacionados sirve para poder acceder desde cualquier
elemento a elementos que por razones del negocio están relacionados
con él mismo.
Si te resulta más facil de comprender imaginemos que
ElementosRelacionados no está en Elemento, que está en algunas clases
finales, Documento, Tarea, Persona, ... y las entidades que puedan
aparecer.
Pero la cosa es que cuando relaciono un documento con una tarea, la
relación debe de existir tanto para la tarea como para el documento.
Olvidate del optimistic-lock.
Lo de usar table-per-concrete-class es por que Entidad y Elemento no
tienen mapping son clases abstractas para la persistencia, si quieres
podrían ser interfaces.
Quizás para que se entendiese mejor debería cambiar:
public class Entidad { ... }
public class Elemento : Entidad { ... }
por:
public abstract class Entidad { ... }
public abstract class Elemento : Entidad { ... }
Hasta donde yo llego, table-per-concrete-class consiste en mapear tan
solo las clases concretas. Clases concretas que persisten sus
propiedades heredadas en tablas separadas.
On 14 dic, 12:44, Fabio Maulo <[email protected]> wrote:
> Cual es la ventaja de meter todo en una misma bolsa de gatos ? (me refiero a
> todas las relaciones en una misma tabla).
>
> No se a que sirve ElementosRelacionados, así como está y menos ya que
> es IList<Elemento>,
> tampoco entiendo que todas las entidades necesiten un control de
> optimistic-lock... repito... Para mi te estas complicando mucho la vida
> professional...
>
> a parte eso, viendo el eschema de clases, no veo ninguna razón por la cual
> usar table-per-concrete-class; para NH no deberían existir ni el mapping de
> Elemento y menos el napping de Entidad.
>
> 2010/12/14 tolemaC <[email protected]>
>
>
>
>
>
> > Me gustaría explicar el trasfondo de por que me surgen estas cosas y
> > otras muchas que voy solucionando poco a poco, si no lo he hecho ya es
> > por no dar la tabarra y por que llevo muy poco tiempo usando un ORM y
> > me falta mucho por aprender. Muchas de las cosas que me han surgido
> > las he solucionado tan solo replanteándolas desde la raíz, pensando en
> > objetos y no en tablas, pero bueno, voy poco a poco.
>
> > A ver si aclaro mis ideas y saco un poco de tiempo y os cuento.
>
> > Volviendo al tema: many-to-any es más o menos lo que buscaba, he
> > encontrado este ejemplo:
>
> > <set name="animals" table="robot_animals">
> > <key column="robot_id"/>
> > <many-to-any id-type="long">
> > <column name="animal_class" not-null="true"/>
> > <column name="animal_id" not-null="true"/>
> > </many-to-any>
> > </set>
>
> > Lo que no se es como NHibernate sabe de que columna coger la clase y
> > de cual el id, supongo que será por el orden de las columnas en el
> > XML.
> > De lo poco que he encontrado en la referencia de NHibernate es:
>
> > "The <many-to-any> and <index-many-to-any> elements provide for true
> > heterogeneous associations. These mapping elements work in the same
> > way as the <any> element - and should also be used rarely, if ever."
>
> > Supongo que al ser un caso extraño no se ha documentado mucho.
>
> > Continuando; con many-to-any podría solucionar el problema creando una
> > tabla de relaciones por cada elemento, de forma que por las clases
> > Tarea, Documento, Persona, ... debería crear las tablas
> > TareaRelaciones, DocumentoRelaciones, PersonaRelaciones, ... pero aquí
> > surge una pega. Si a la "Tarea 4" le asocio el "Documento 3", guardará
> > la relación en la tabla TareaRelaciones. Cuando carge la tarea 4
> > tendré el documento 3 como elemento relacionado, el problema es que
> > cuando cargue el "documento 3" irá a cargar las relaciones en la tabla
> > DocumentoRelaciones y no encontrará la relación con la "tarea 4".
>
> > Es por esto que mi idea inicial era tener todas las relaciones en una
> > misma tabla.
> > Tendría que buscar la forma de decirle al many-to-any como montar el
> > where para buscar las relaciones y como extraer la entidad
> > relacionada.
>
> > Algo así:
>
> > <set name="ElementosRelacionados" table="Relaciones">
> > <many-to-any-TwoWay-EXTREME>
> > <class-key-columns column1="ClaseElemento1"
> > column2="ClaseElemento2"/>
> > <id-key-columns column1="IdElemento1" column2="IdElemento2"/>
> > </many-to-any-TwoWay-EXTREME>
> > </set>
>
> > Quizás suene a risa :?, pero con algo así se podrían relacionar todo
> > tipo de entidades dentro de un dominio.
> > Quizás me esté complicando la vida profesional :?, pero esto me ahorra
> > editar muchos mappings y da una versatilidad extraordinaria en un
> > dominio cualquiera.
>
> > Saludos,
>
> > On 14 dic, 11:18, Fabio Maulo <[email protected]> wrote:
> > > Para mi te estas complicando mucho la vida professional... de todas
> > formas
> > > estas buscando: many-to-any
>
> > > 2010/12/13 tolemaC <[email protected]>
>
> > > > Hola gente,
>
> > > > Me ha surgido algún que otro problema a la hora de mapear las
> > > > entidades de un dominio, no se por donde cogerlo y necesito ideas.
>
> > > > En mi dominio manejo dos tipos de entidades, las que llamo Entidades
> > > > por que tienen un Id y una versión y otras entidades de más peso que
> > > > heredan de entidad pero también tienen nombre, descripción y un flag
> > > > de activación/desactivación. A estas últimas las he llamado
> > > > "Elementos", en código son esto:
>
> > > > public class Entidad
> > > > {
> > > > public virtual int Id { get; set; }
> > > > public virtual int Version { get; set; }
> > > > }
>
> > > > public class Elemento : Entidad
> > > > {
> > > > public virtual string Nombre { get; set; }
> > > > public virtual string Descripcion { get; set; }
> > > > public virtual bool Desactivado { get; set; }
> > > > public virtual IList<Elemento> ElementosRelacionados { get;
> > > > set; }
> > > > }
>
> > > > La clase Elemento también tiene una lista de otros elementos que
> > > > están, por algún motivo, relacionados en él mismo.
>
> > > > Bien, todas las entidades de mi dominio heredan de entidad o elemento,
> > > > como ejemplo tengo entidades llamadas, Persona, Tarea, Documento y
> > > > Ejecutor, este es el diagrama de clases que forman:
>
> > > >http://jros.org/files/orm/elementos.png
>
> > > > Como podéis ver Persona, Ejecutor, Tarea y Documento heredan directa o
> > > > indirectamente de Elemento.
> > > > Para el caso quiero usar table-per-concrete-class para mapear mis
> > > > entidades, y el problema me viene en que no se como mapear la
> > > > propiedad "ElementosRelacionados" para cada una de las clases
> > > > concretas.
>
> > > > Pensándolo un poco mi idea es usar una tabla llamada "Relaciones"
> > > > donde relacionar las entidades, teniendo como campos "ClaseElemento1",
> > > > "ClaseElemento2", "IdElemento1" y "IdElemento2". En los dos primeros
> > > > pondría el nombre de la clase del elemento y en los segundos los
> > > > Identificadores.
>
> > > > Todo esto debería funcionar teniendo en cuenta:
>
> > > > 1) Cualquier elemento se puede relacionar con cualquier otro. Hoy son
> > > > Documento, Tarea, Persona y Ejecutor, pero mañana pueden aparecer
> > > > Expediente, Proyecto, Factura, ... Me gustaría hacerlo de forma
> > > > genérica para que me valga para cualquier tipo de entidad.
>
> > > > 2) Un Documento puede estar relacionado con una Tarea y viceversa.
> > > > Cuando voy a buscar los Elementos relacionados con una Tarea, debo
> > > > mirar en la tabla de relaciones si se encuentra como Elemento1 o como
> > > > Elemento2, a ambos lados de la relación.
>
> > > > En fin, me ha parecido lo suficientemente interesante como para
> > > > plantearlo aquí.
>
> > > > Aquí van las tablas como más o menos las tengo pensadas:
> > > >http://jros.org/files/orm/tablas1.png
>
> > > > Alguna idea?
>
> > > > --
> > > > Para escribir al Grupo, hágalo a esta dirección:
> > > > [email protected]
> > > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano
>
> > > --
> > > Fabio Maulo
>
> > --
> > Para escribir al Grupo, hágalo a esta dirección:
> > [email protected]
> > Para más, visite:http://groups.google.com/group/NHibernate-Hispano
>
> --
> Fabio Maulo
--
Para escribir al Grupo, hágalo a esta dirección:
[email protected]
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
