HERENCIA - SUBCLASES

59 views
Skip to first unread message

alejjjo

unread,
Jul 29, 2006, 7:52:17 PM7/29/06
to NHibernate-Hispano
HOLA A TODOS! YA LUEGO DE LEER BASTANTE TENGO MI APLICACION ANDANDO CON
NHIBERNATE, Y SQL SERVER 2005. YA LE ARME UNA FACHADA Y LA VERDAD Que
trabajar asi es fantástico.

Tengo un problema, con la herencia, ya que en el modelo relacional no
existe hay que emularla. Pero el polimorfismo es un problema.. Les
comento mi situación, y veamos si se puede encontrar una solución.

Supongamos que tengo 3 clases:

Persona (clave primaria en tabla: nro de documento)
Cliente
Proveedor

persona es la superclase, y cliente y proveedor son subclases de
persona.

Supongamos que use la estrategia de mapeo tabla por jerarquía de
clases, o sea, en la BD tengo una sola tabla Persona, y ahi persisto
objetos del tipo persona, cliente y proveedor, tengo un campo que es el
discriminador, para saber q tipo de objeto es el que se guardó.

Ahora bien, supongamos que trabajo con una persona que es cliente de la
empresa, entonces creo un objeto cliente, y luego lo persisto en la BD.

Luego si esa misma persona, ingresa como proveedor al sistema... hay
caos.

Al querer persistirlo, como ya hay una Persona con esa clave
primaria(su DNI o nro de doc), no me deja agregarlo. Una sería
eliminarlo y guardarlo como Proveedor... pero no me convence eso, ya
que si interactúa de nuevo como cliente, debería volver a
convertirlo.

Otra que se me ocurrio es la posibilidad de que la clave primaria en la
BD sea aparte del DNI, sea el DNI + discriminador, de esta manera
podría haber objetos persistidos con el mismo dni, en distintas
subclases. Pero esto no se como poder implementarlo en los xml de
mapeo.

Bueno la otra solución mas elegante que encontre, es usar la
estrategia tabla por clase concreta, al tener tres tablas distintas,
no ocurre el problema de que no pueda tener 1 persona con 2 roles
distintos. El gran problema que tiene esto, es que obviamente si
modifico algún dato de la persona Cliente, el objeto Proveedor de esa
misma persona, no vera reflejado esas modificaciones.

La otra estrategia de persistencia de herencia, de tener las tablas de
las subclases relacionadas con la de la superclase, con
joined-subclass, tampoco sirve, ya que ambas subclases deben tener el
mismo id que la superclase, y ahi se generan filas repetidas.

Al menos esto es lo que yo experimenté e investigue. Estaría muy
bueno que entre todos podamos llegar a una conclusión, es algo que
complica trabajar con objetos, o sea, una vez que entra la persistencia
en juego, ya la complica con la herencia...y empezar a adaptar la forma
de programar en objetos a relacional... no es muy lindo ya que es como
que todo lo bueno de objetos se va al carajo! (he estado frente a la
pantalla demasiadas horas hoy, entiendanme:P)

Bueno, Espero sus comentarios!

Ezequiel Jadib

unread,
Jul 29, 2006, 8:41:02 PM7/29/06
to NHibernat...@googlegroups.com
tendrias que pensar mejor el modelo de datos.. sin saber el dominio que estas queriendo modelar es dificil darte una ayuda concreta...
 
pero puede haber varias formas, despues se vera si hay cosas bien o mal.. pero por ejemplo podrias tener la tabla Personas, y una tabla de tipos de persona

y una n:n para modelar que una persona es un cliente y un proveedor.. aunque quizas esta opcion te haria poner muchas cosas en la clase persona para poder cumplir los dos tipos.
 
igualmente, con la opcion de las tres tablas...
no tendrias que tener el problema ese que comentas..
 
porque 1) si tratando a la persona como cliente, te cambia algo en el cliente.. es obvio que el proveedor no lo va a ver, y esta bien que no lo haga.
2) ahora si tu problema es si lo tendria que ver el proveedor, entonces tampoco el problema esta ahi, sino el problema es que generalizaste mal, y ese dato lo tendrias que pasar a la persona si queres que el proveedor lo vea al cambiar.
3) podrias implementar algun evento o un interceptor para que cuando cambie el cliente, actualize el proveedor por ejemplo...
 
con ejemplos mas concretos y con una idea del dominio que estas intentando modelar, creo que mucha mas gente podria ayudarte.
 
saludos 


    Ezequiel Jadib

*
eja...@rdi2k.com
* MSN: ezequi...@hotmail.com
& Blog: ejadib.wordpress.com

1 San Martin 617 P. 2 B
( (54-11)4893-1694
:
www.rdi2k.com

Fabio Maulo

unread,
Jul 30, 2006, 12:19:37 AM7/30/06
to NHibernat...@googlegroups.com
Fijate si lo que te sirve es el thread de este foro cuyo titulo es:
"Generalizacion-Especializacion"
Chau.
Fabio.

alejjjo escribió:

alejjjo

unread,
Jul 30, 2006, 4:56:15 PM7/30/06
to NHibernate-Hispano
Hola Ezequiel, gracias por tu respuesta.

Asi es como lo tengo, con las tres tablas independientes. Y ahora
pensandolo como objetos, esta bien que no se pueda acceder a un objeto
de la subclase, como otra clase de otra rama de herencia.

A lo que me refería, es que si se mapeaba de las otras dos maneras, se
lanzaba una excepción, ya que como las 3 clases guardaban los id en la
misma clase, y los 2 objetos van a tener el mismo id, no puedo
almacenar a esa misma persona con 2 roles distintos (2 subclases de
persona).

Como corolario o conclusión de esto:

Si quiero mapear 1 superclase, y 2 subclases, y en mi sistema podría
ocurrir tener 2 objetos, 1 de cada subclase, con el mismo id (que se
define en la superclase),

entonces la única estrategia viable de mapeo es la de tener una tabla
por clase concreta.
-----

Bueno les voy a comentar brevemente el caso con el que me surgió la
duda, a ver si a alguien se le ocurre algo mas.

Es un sistema para una cooperativa de trabajo.
Tengo una clase Persona, y 2 clases q heredan de persona, Asociado y
Dueño.

Dueño tiene relación con otra clase llamada Empresa, y
asociado(sería un trabajador en una empresa) tiene una relación con
asignacion... etc.

En este caso es muy raro que se de lo que planteé anteriormente...
pero supongamos que una persona es asociado y esta trabajando en una
empresa. Luego esta persona tiene una empresa y empieza a trabajar con
la Cooperativa... entonces también lo ingresaría al sistema como un
objeto Dueño. Entonces hasta ahi en objetos estaría todo bien, pero
al mapearlo a las tablas, con las 2 primeras estrategias(1 sola tabla
para toda la rama de herencia, y tablas asociadas o joined subclass)
daría un error de violación de llave primaria la BD.

Lo solucioné de la manera que les comenté, con la tercer estrategia
de mapeo de herencia ( 1 tabla por clase concreta).

Ahora puedo tener un Dueño cargado y un Asociado, con el mismo id.

Les comento que el modelo de diseño OO es correcto, se podrían hacer
modificaciones para evitar la herencia, como en vez de heredar, crear
un objeto Dueño que se asocie a uno Persona, y un obj Asociado que
este asociado al obj Persona... pero lo que quiero discutir es si hay
una forma de mapear a relacional correctamente una herencia.

Muchas gracias a todos!

Alejandro Perez Albiero


Ezequiel Jadib wrote:
> tendrias que pensar mejor el modelo de datos.. sin saber el dominio que estas queriendo modelar es dificil darte una ayuda concreta...
>
> pero puede haber varias formas, despues se vera si hay cosas bien o mal.. pero por ejemplo podrias tener la tabla Personas, y una tabla de tipos de persona
>
> y una n:n para modelar que una persona es un cliente y un proveedor.. aunque quizas esta opcion te haria poner muchas cosas en la clase persona para poder cumplir los dos tipos.
>
> igualmente, con la opcion de las tres tablas...
> no tendrias que tener el problema ese que comentas..
>
> porque 1) si tratando a la persona como cliente, te cambia algo en el cliente.. es obvio que el proveedor no lo va a ver, y esta bien que no lo haga.
> 2) ahora si tu problema es si lo tendria que ver el proveedor, entonces tampoco el problema esta ahi, sino el problema es que generalizaste mal, y ese dato lo tendrias que pasar a la persona si queres que el proveedor lo vea al cambiar.
> 3) podrias implementar algun evento o un interceptor para que cuando cambie el cliente, actualize el proveedor por ejemplo...
>
> con ejemplos mas concretos y con una idea del dominio que estas intentando modelar, creo que mucha mas gente podria ayudarte.
>
> saludos
>

> ------=_NextPart_001_0035_01C6B357.B06B8180
> Content-Type: text/html; charset=iso-8859-1
> Content-Transfer-Encoding: quoted-printable
> X-Google-AttachSize: 7416
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
> <META content="MSHTML 6.00.2900.2912" name=GENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY>
> <DIV><FONT face=Arial size=2>tendrias que pensar mejor el modelo de datos.. sin


> saber el dominio que estas queriendo modelar es dificil darte una ayuda

> concreta...</FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>pero puede haber varias formas, despues se vera si


> hay cosas bien o mal.. pero por ejemplo podrias tener la tabla Personas, y una

> tabla de tipos de persona<BR><BR>y una n:n para modelar que una persona es un


> cliente y un proveedor.. aunque quizas esta opcion te haria poner muchas cosas

> en la clase persona para poder cumplir los dos tipos.</FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>igualmente, con la opcion de las tres
> tablas...</FONT></DIV>
> <DIV><FONT face=Arial size=2>no tendrias que tener el problema ese que
> comentas..</FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>porque 1) si tratando a la persona como cliente, te


> cambia algo en el cliente.. es obvio que el proveedor no lo va a ver, y esta

> bien que no lo haga.</FONT></DIV>
> <DIV><FONT face=Arial size=2>2) ahora si tu problema es si lo tendria que ver el


> proveedor, entonces tampoco el problema esta ahi, sino el problema es que
> generalizaste mal, y ese dato lo tendrias que pasar a la persona si queres que

> el proveedor lo vea al cambiar.</FONT></DIV>
> <DIV><FONT face=Arial size=2>3) podrias implementar algun evento o un
> interceptor&nbsp;para que cuando cambie el cliente, actualize el proveedor por
> ejemplo...</FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>con ejemplos mas concretos y con una idea del


> dominio que estas intentando modelar, creo que mucha mas gente podria

> ayudarte.</FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>saludos&nbsp;</FONT></DIV>
> <DIV><FONT face=Arial size=2>
> <P><FONT face=Wingdings><FONT face=Verdana><IMG
> src="cid:003301c6b370$d5b18d90$6701a8c0@EzequielJadib"><BR><FONT size=2><FONT
> face=Verdana size=3>&nbsp;&nbsp;&nbsp;&nbsp;</FONT>Ezequiel Jadib</FONT>
> </FONT><BR>*</FONT><FONT face=Verdana> <A href="mailto:eja...@rdi2k.com"><FONT
> size=2>eja...@rdi2k.com</FONT></A><BR></FONT><FONT face=Wingdings>*</FONT><FONT
> face=Verdana> <FONT size=2>MSN: </FONT><A
> href="mailto:ezequi...@hotmail.com"><FONT
> size=2>ezequi...@hotmail.com</FONT></A><BR><FONT
> face=Wingdings>&amp;</FONT><FONT face=Verdana> <FONT size=2>Blog: </FONT><A
> href="http://ejadib.wordpress.com"><FONT
> size=2>ejadib.wordpress.com</FONT></A><BR></FONT><FONT face=Wingdings><BR>1<FONT
> face=Verdana size=2> San Martin 617 P. 2 B</FONT> <BR>(<FONT face=Verdana> <FONT
> size=2>(54-11)4893-1694</FONT> </FONT><BR><FONT
> face=Wingdings>:</FONT></FONT><FONT face=Verdana> <A
> href="http://www.rdi2k.com"><FONT
> size=2>www.rdi2k.com</FONT></A></FONT></P></FONT></FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>----- Original Message ----- </FONT>
> <DIV><FONT face=Arial size=2>From: "alejjjo" &lt;</FONT><A
> href="mailto:palale...@gmail.com"><FONT face=Arial
> size=2>palale...@gmail.com</FONT></A><FONT face=Arial
> size=2>&gt;</FONT></DIV>
> <DIV><FONT face=Arial size=2>To: "NHibernate-Hispano" &lt;</FONT><A
> href="mailto:NHibernat...@googlegroups.com"><FONT face=Arial
> size=2>NHibernat...@googlegroups.com</FONT></A><FONT face=Arial
> size=2>&gt;</FONT></DIV>
> <DIV><FONT face=Arial size=2>Sent: Saturday, July 29, 2006 8:52 PM</FONT></DIV>
> <DIV><FONT face=Arial size=2>Subject: [NHibernate-Hispano] HERENCIA -
> SUBCLASES</FONT></DIV></DIV>
> <DIV><FONT face=Arial><BR><FONT size=2></FONT></FONT></DIV><BR><FONT face=Arial
> size=2>HOLA A TODOS! YA LUEGO DE LEER BASTANTE TENGO MI APLICACION ANDANDO
> CON<BR>NHIBERNATE, Y SQL SERVER 2005. YA LE ARME UNA FACHADA Y LA VERDAD
> Que<BR>trabajar asi es fantástico.<BR><BR>Tengo un problema, con la herencia, ya
> que en el modelo relacional no<BR>existe hay que emularla.&nbsp; Pero el
> polimorfismo es un problema.. Les<BR>comento mi situación, y veamos si se puede
> encontrar una solución.<BR><BR>Supongamos que tengo 3 clases:<BR><BR>Persona


> (clave primaria en tabla: nro de

> documento)<BR>Cliente<BR>Proveedor<BR><BR>persona es la superclase, y cliente y
> proveedor son subclases de<BR>persona.<BR><BR>Supongamos que use la estrategia
> de mapeo tabla por jerarquía de<BR>clases, o sea, en la BD tengo una sola tabla
> Persona, y ahi persisto<BR>objetos del tipo persona, cliente y proveedor, tengo
> un campo que es el<BR>discriminador, para saber q tipo de objeto es el que se
> guardó.<BR><BR>Ahora bien, supongamos que trabajo con una persona que es cliente
> de la<BR>empresa, entonces creo un objeto cliente, y luego lo persisto en la
> BD.<BR><BR>Luego si esa misma persona, ingresa como proveedor al sistema...
> hay<BR>caos.<BR><BR>Al querer persistirlo, como ya hay una Persona con esa
> clave<BR>primaria(su DNI o nro de doc), no me deja agregarlo.&nbsp; Una
> sería<BR>eliminarlo y guardarlo como Proveedor... pero no me convence eso,
> ya<BR>que si interactúa de nuevo como cliente, debería volver
> a<BR>convertirlo.<BR><BR>Otra que se me ocurrio es la posibilidad de que la
> clave primaria en la<BR>BD sea aparte del DNI, sea el DNI + discriminador, de
> esta manera<BR>podría haber objetos persistidos con el mismo dni, en
> distintas<BR>subclases.&nbsp; Pero esto no se como poder implementarlo en los
> xml de<BR>mapeo.<BR><BR>Bueno la otra solución mas elegante que encontre, es
> usar la<BR>estrategia&nbsp; tabla por clase concreta, al tener tres tablas
> distintas,<BR>no ocurre el problema de que no pueda tener 1 persona con 2
> roles<BR>distintos.&nbsp; El gran problema que tiene esto, es que obviamente
> si<BR>modifico algún dato de la persona Cliente, el objeto Proveedor de
> esa<BR>misma persona, no vera reflejado esas modificaciones.<BR><BR>La otra
> estrategia de persistencia de herencia, de tener las tablas de<BR>las subclases
> relacionadas con la de la superclase, con<BR>joined-subclass, tampoco sirve, ya
> que ambas subclases deben tener el<BR>mismo id que la superclase, y ahi se
> generan filas repetidas.<BR><BR>Al menos esto es lo que yo experimenté e
> investigue.&nbsp; Estaría muy<BR>bueno que entre todos podamos llegar a una
> conclusión, es algo que<BR>complica trabajar con objetos, o sea, una vez que
> entra la persistencia<BR>en juego, ya la complica con la herencia...y empezar a
> adaptar la forma<BR>de programar en objetos a relacional... no es muy lindo ya
> que es como<BR>que todo lo bueno de objetos se va al carajo! (he estado frente a
> la<BR>pantalla demasiadas horas hoy, entiendanme:P)<BR><BR>Bueno, Espero sus
> comentarios!<BR><BR><BR>
> ------=_NextPart_001_0035_01C6B357.B06B8180--

alejjjo

unread,
Jul 30, 2006, 5:07:29 PM7/30/06
to NHibernate-Hispano
Hola! gracias Favio ya lo habia leído antes, me sirvió para ubicarme
je, pero no es lo que planteo. Recién volvi a postear explicando un
poco mejor, leanlo bien a ver si les sirve y quizas desde otro punto de
vista se puede pulir mejor mi idea! gracias!!

Alejandro.

Fabio Maulo

unread,
Jul 30, 2006, 6:15:43 PM7/30/06
to NHibernat...@googlegroups.com
Podrias enviar solo el esquema de objetos?
Alcanzaria con algo tipo
ObjA
^
ObjB
^ ^
ObjC ObjD

ObjB hereda de ObjA; ObjC y ObjD hereda de ObjB.
Mandá en modelo de objetos y veremos que formas hay de mapearlos.
Chau.
Fabio.

alejjjo escribió:

alejjjo

unread,
Jul 31, 2006, 12:47:49 PM7/31/06
to NHibernate-Hispano
Fabio, aca te paso el modelo de datos:

Persona
^ ^
Asociado Dueño


Si una persona es en el sistema Asociado y Dueño a la vez, ahi surge
la cuestión comentada. el Id de persona es el DNI. Fijate si con
esto y releyendo lo q posteé antes te queda mas claro. Gracias!

Alejandro.

Fabio Maulo

unread,
Aug 1, 2006, 12:51:01 AM8/1/06
to NHibernat...@googlegroups.com
El problema está en el esquema de clases y no en el mapeo.
Creo que el tema deriva de la errónea interpretación que, a veces, le
damos a la herencia.
Con la herencia heredamos propiedades y comportamiento pero estamos
siempre ablando de cosas distintas.
Te hago un ejemplo con perros (para salir un poco de la monotonía del
negocio).

Supongamos que haya un chabon que viva en un pueblo de la colinas del
centro de Italia y que sea un pastor de ovejas.
Ese chabon tiene perros pastores y perros guardianes.
Resumo esta situación:
- Hay perros
- Alguno trabaja como pastor
- Algún otro trabaja como guardián
Una forma, que se me podría ocurrir para representarlo en clases es:
-Clase Perro
-Clase PerroPastor que hereda de Perro
-Clase PerroGuardian que hereda de Perro
De esta forma si escribo:
PerroPastor pp = new PerroPastor();
PerroGuadian pg = new PerroGuardian();
Perro p = new Perro();
estoy representando tres perros distintos;el ultimo sería un perro CCMD
( come,..,..,duerme ;) ).

El tema es que ese chabon no me había dicho que en realidad tiene un
perro, muy bueno, que es capaz de trabajar sea como pastor que como
guardián.
Esta ultima frase me abre un poco la cabeza......
El Perro es perro! el tema es que puede asumir uno o mas ROLES o sea
puede tener sea el ROL de pastor que el ROL de guardián.
Así cambio mi esquema de clases; ahora tengo una clase Perro que tiene
relación con la clase PerroGuardian y/o con la clase PerroPastor.
La relación entre estas clases puede representarse de varias formas; en
principio podríamos afirmar que hay una relación one-to-one ya que
cuando se hablará de las característica de Guardián se hablará de un
perro especifico (por ejemplo se habla del perro cuyo nombre es "Lupo",
de raza ..., que tiene un nivel de atención .... ).
Si quiero representarlo con clases puedo decir:
- que la clase Perro me tiene que dar el servicio de conocer cuales son
los roles que puede asumir un perro especifico (perro
especifico=instancia de la clase Perro)
- que la clase PerroGuardian me tiene que dar el servicio de conocer a
cual perro especifico se refieren las propiedades de guardián
- que la clase PerroPastor me tiene que dar el servicio de conocer a
cual perro especifico se refieren las propiedades de pastor
Esta relación es una representación one-to-one clásica de NHb (si te
interesa podemos discutir el mapeo)

Hay otras formas de representar relaciones one-to-one en NHb, algunas te
lleva a mapear la relación como many-to-one, todo, obviamente, depende
del esquema de clases.

Fijate si esta historia de las colinas del centro Italia contesta tu
inquietud.

Chau.
Fabio.

P.D. Aprovecho para aconsejarte de no usar el DNI como ID, si no te es
mucho trabajo sería mejor evitar de usar ID que se mezclan con reglas de
negocio.

alejjjo escribió:

alejjjo

unread,
Aug 1, 2006, 11:39:39 AM8/1/06
to NHibernate-Hispano
Fabio muy bueno tu ejemplo, la verdad terminó de aclararme del todo
algo que estaba pensando.

Lo que me dí cuenta es que mi modelo de clases no representa bien la
realidad, y que el problema que planteé, no es un problema del mapeo,
sino de el modelo de clases que armé. Esto lo digo porque (siguiendo
tu ejemplo de herencia de los perros) una instancia perro guardián
nunca podrá ser una instancia perro pastor.

No creo que sea mucho trabajo agregar una propiedad más para usarla
como ObjectId, y la verdad creo que todos estos problemas se
solucionarían. Gracias por tu recomendación.

Igual estaría bueno dejar en claro que cuando se presente una
situación donde tenga que mapear el Id de reglas de negocio, como
llave primaria en la tabla, como en el caso de dni persona, la mejor
opción de mapeo es la de tener una tabla mapeada por clase concreta,
así se evitaría que ocurriesen infracciones a la restricción de
llave primaria en dicha tabla.

Volviendo a mi modelo de clases, lo voy a dejar como lo tengo, con la
rama de herencia, ya que representa la situación real de manera
adecuada. El tema que planteé de que si un Asociado alguna vez es
Dueño, es muuuuy remota.

Igual voy a analizarlo como me comentabas, creando relaciones entre la
clase persona y Asociado y entre Persona y Dueño. Pero supongamos que
una persona puede asumir los 2 roles, no tendría que estar asociada
con los 2 roles? me parece que mas que uno a uno sería n a uno, en fin
si quieren luego lo posteo y lo discutimos.

Muchisimas gracias por haber respondido con tanto esmero a todos!


Alejandro Perez Albiero.

alejjjo

unread,
Aug 1, 2006, 11:44:05 AM8/1/06
to NHibernate-Hispano
Otra cosita, estaba pensando, de usar un ID distinto a algún ID
natural de las reglas del negocio, con esto perderíamos la protección
del motor de BD, ya que, con una programación descuidada, se podrían
almacenar 1 persona 2 veces en la BD. Ya se! ya se... si no se
programa bien, va a salir cualquier cosa je. Pero quería dejar en
claro que si se usa otro ID, se pierde ese control extra de la BD.

Saludos!

Ezequiel Jadib

unread,
Aug 1, 2006, 12:19:19 PM8/1/06
to NHibernat...@googlegroups.com
podes poner una unique key y no perdes ese control extra

----- Original Message -----
From: "alejjjo" <palale...@gmail.com>
To: "NHibernate-Hispano" <NHibernat...@googlegroups.com>

Fabio Maulo

unread,
Aug 1, 2006, 12:27:42 PM8/1/06
to NHibernat...@googlegroups.com
Cuando te dicen que "es muuuuy remota" no le creas, y creele menos si
estas en Argentina.
Viste como es acá... hoy no tenes plata, mañana tenes un montón y pasado
te la sacan toda o no vale nada....
Ya que te dijeron que está la posibilidad que pase hay que incluirla en
el diseño (y en el presupuesto obviamente)... dejá que te lo diga uno
que hace 18 años que programa para empresas.

Chau.
Fabio.

alejjjo escribió:

alejjjo

unread,
Aug 1, 2006, 7:23:38 PM8/1/06
to NHibernate-Hispano
jaja si es verdad, aunque este sistema lo estoy armando a modo de tesis
para analista de sistemas, asi que lo del presupuesto queda afuera:P.

Igual fijate en el post, al final te preguntaba algo en cuanto a la
cardinalidad..

Gracias!

alejjjo

unread,
Aug 1, 2006, 7:26:56 PM8/1/06
to NHibernate-Hispano
hola Ezequiel! no se si entendi bien a que te referias, supongo que
decias de poner ese campo en la base de datos como llave, te referias
al DNI o al OID?

Si te referias al DNI, seguiría teniendo el mismo problema, ya que no
podría guardarlo 2 veces, y si es el OID, ese si que tiene que ir como
llave primaria, pero igual podría permitir q 1 dni estuviese 2 o mas
veces en la BD.

Entendi bien o mal? saludos!

Ezequiel Jadib

unread,
Aug 1, 2006, 10:11:28 PM8/1/06
to NHibernat...@googlegroups.com
no
tu clase persona tiene que tener esto

Id = PrimaryKey
DNI = UniqueKey (para no permitir repetidos)

saludos


----- Original Message -----
From: "alejjjo" <palale...@gmail.com>
To: "NHibernate-Hispano" <NHibernat...@googlegroups.com>
Sent: Tuesday, August 01, 2006 8:26 PM
Subject: [NHibernate-Hispano] Re: HERENCIA - SUBCLASES

Fabio Maulo

unread,
Aug 2, 2006, 12:28:59 AM8/2/06
to NHibernat...@googlegroups.com
Si te fijas en el mail de los perro está escrito... después como
implementarlo es cuestión de gustos/necesidades.
-Persona puede tener dos propiedades respectivamente de tipo Dueño y
Asociado (puden ser valorizadas las dos o una de las dos puede estar a
null o las dos a null según necesite tu diseño)
-Dueño y Asociado tendrán una propiedad de tipo Persona que NO puede ser
null.
-Dueño y Asociado tienen una relación one-to-one con Persona

Si quieres podes hacerlo mas complejo:
-Persona tiene una collection<IRolAsociacion>
-Dueño y Asociado tienen que implementar IRolAsociacion
etc.

El "puede tener" de la clase Persona depende de los use case que
tienes.... ya que es para una tesis podes divertirte a inventar
requerimientos.
Bye.
Fabio.

P.D. ya que es una tesis ponete a estudiar y pasanos la tesis cuando la
termines.

alejjjo escribió:

Reply all
Reply to author
Forward
0 new messages