No me refería a union-subclass. Cuando dije que quería usar table-per-
concrete-class me refería a usar una tabla por cada clase final, es
decir mapear las clases finales documento, persona, tarea y ejecutor.
Nunca pensé en mapear Entidad ni Elemento, por que como tu dices para
mi no son entidades de mi dominio.

Si tienes user relacionado con Imagenes, videos y comentarios, en el
mapping de user tendrás en la clase User una colección por cada de las
entidades relacionadas, algo así:

public class User {
  ...
  public virtual ICollection Images;
  public virtual ICollection Videos;
  public virtual ICollection Coments;
}

Eso implica que si quieres relacionar User con una nueva entidad,
tienes que tocar la clase user, el mapping user, probar, recompilar,
publicar y notificar el cambio a los usuarios :)

Yo quiero ahorrarme eso, por que, aunque pienses que me complico la
vida profesional, tenerlo todo junto me ahorra trabajo.
Ahora viene la pregunta: ¿Tanto cambian tus entidades?, la respuesta
es "Si".

Además, yo no quiero ninguna bolsa de gatos, yo simplemente quiero
poder acceder a elementos relacionados con una sola propiedad a la que
he llamado "ElementosRelacionados", la culpa la tiene la Base de datos
que me hace inventarme cosas raras para poder mapear mi dominio.

Una aclaración más: Nunca voy a meter a un cliente en los elementos
relacionados de una Factura.
Factura tendrá su cliente, pero necesito que si el usuario de mi
aplicación quiere asociar una Banana a una Factura lo pueda hacer,
como si quiere asociar un Mono a una Rama de un Banano y por último
asociar este Banano a la Banana de la Factura y así tenerlo todo
junto :)
Lo que no puedo hacer es que si asocio una Banana a un Mono es que al
consultar el Mono no tenga la Banana como elemento relacionado. La
relación es bidireccional. La banana aparecerá como asociado del mono
y el mono como asociado de la Banana.

Borremoslo todo, el hecho de hablar de una sola bolsa que lo incluya
todo ha sido por que no quería plantear la duda sin aportar alguna
idea inicial, por lo menos dejar ver que lo he estado pensando un
poco :)

Saludos Fabio y gracias por tu tiempo,


On 14 dic, 13:21, Fabio Maulo <[email protected]> wrote:
> te pregunto: quien te dijo que a NH le interesa el mapping de esas dos
> clases de base ?
> podes mapear directamente Persona, Tarea etc. sin especificar, en el
> mapping, que heredan de algo mas (o sea sin usar table-per-concrete-class
> aka union-subclass).
> table-per-concrete-class tiene a que ver con algo de lo que mencionaste pero
> se refiere a representacción de persistencia de herencia de entidades (tus
> clases Entidad y Elemento no son 
> entidades).http://altnet-hispano.pbworks.com/w/page/12367724/van-2009-09-19-intr...
>
> Si en ElementosRelacionados, metes cualquier entidad... bueno... bancate el
> many-to-any...
> Yo tengo User que está relacionado con varias entidades como Imagenes,
> Videos, Comentarios, Clasificados, Pagos etc. etc. y en mi domain-model no
> tengo la bolsa de gatos (tampoco está en el persistent-model).
>
> 2010/12/14 tolemaC <[email protected]>
>
>
>
> > 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
>
> ...
>
> leer más »

-- 
Para escribir al Grupo, hágalo a esta dirección: 
[email protected]
Para más, visite: http://groups.google.com/group/NHibernate-Hispano

Responder a