Gastón Nola Alonso
Tue, 17 Nov 2009 16:30:47 -0800
P.D.: En otro hilo había visto una "regla" para decidir si hacer one-
to-many o many-to-many que iba mas o menos de esta forma: Si podés
nombrar la relación del medio (entre dos entidades distintas) de otra
forma que Entidad1Entidad2, es one-to-many.
Ya se que no debe ser tomada a rajatabla, pero me pareció que tenía
sentido.
On 17 nov, 22:17, Gastón Nola Alonso <gnol...@gmail.com> wrote:
> En realidad muy errado no andás; existen, efectivamente, las clases
> Cliente y Reserva, pero no afectan a lo anterior (la asignación de
> comodidades se asignan independientemente de las preferencias del
> cliente. Es una onda "si te gusta bien, sino...").
>
> La pifié yo al decir lo de las estadísticas, puesto que como es una
> entrega en la facultad, los requerimientos ya están explicitados y no
> van a cambiar. Lo que quiero decir es que muy probablemente no se
> utilicen las estadísticas y el único fin de la relación Habitación-
> Comodidad es para impedir la eliminación de una Comodidad asignada a
> (por lo menos) una Habitación. Ya se que podría haber solucionado el
> tema con un contador de referencias, pero además de ser más "prolijo",
> creo que me va facilitar la vida en cuanto a otros requerimientos (la
> verdad que no he pensado/implementado todos ellos).
>
> Bajo esta nueva luz, ¿está mal pensado mi razonamiento?
>
> Saludos y gracias por las respuestas!
>
> On 17 nov, 21:10, Carlos Peix <carlos.p...@gmail.com> wrote:
>
> > Hola Gaston,
>
> > Cada vez que veo una tabla de relacion sin columnas ademas de los IDs de las
> > tablas relacionadas, mi olfato me dice que podria formalizarse con un objeto
> > que represente la relacion y darle a ese objeto semantica del dominio.
>
> > Fijate que en el caso que te envie, el objeto si tiene otro dato mas que las
> > referencias. Es el periodo en que esa Comodidad se asocio a esa Habitacion.
> > Ese dato es el que te va a permitir obtener estadisticas de uso de de la
> > comodidad (sumando los periodos de uso y comparando con el tiempo de vida de
> > la comodidad).
>
> > Ahora que charlamos mas sobre el dominio se me ocurre que la relacion
> > tampoco seria entre la habitacion y la comodidad (suponiendo que el pasajero
> > elije las comodidades que desea).
>
> > Si el parrafo anterior es correcto, entonces habria que introducir el
> > concepto de "un pasajero en una habitacion", pongamos Reserva, aunque no me
> > gusta mucho. Entonces esta reserva es la que se asocia a una comodidad.
>
> > Tambien es cierto que me estoy aventurando mucho sin conocer el dominio asi
> > que te pido disculpas si erro la idea.
>
> > Un saludo
>
> > ----------------------------------
> > Carlos Peix
>
> > 2009/11/17 Gastón Nola Alonso <gnol...@gmail.com>
>
> > > Hola Carlos, gracias por tu pronta respuesta. Creo que entiendo tu
> > > idea y -corregime si me equivoco- básicamente lo que haría sería una
> > > relación uno-a-muchos, y debería mapear esa entidad ¿no?
>
> > > En realidad creo que es una buena solución, pero en cierto modo siento
> > > que estoy haciendo trampa; al fin y al cabo, la asignación no posee
> > > más datos que la referencia a la habitación y la comodidad.
>
> > > P.D.: Sí, las comodidades son lo que pusiste como ejemplo.
>
> > > On 17 nov, 20:12, Carlos Peix <carlos.p...@gmail.com> wrote:
> > > > Hola Gaston,
>
> > > > Dado que veo que estan prestando atencion al modelo del dominio, te
> > > planteo
> > > > mi interpretacion.
>
> > > > Suponiendo que una Comodidad sea algo asi como "TV por cable" o
> > > "Frigobar" o
> > > > "Caja de seguridad", es decir, algo que se lo activan o desactivan a la
> > > > habitacion, entonces un mejor modelo me parece este:
>
> > > > Objetos: Habitacion, Comodidad y AsignacionComodidad con el siguiente
> > > > esquema.
>
> > > > class Habitacion {
> > > > IList<Comodidad> comodidades
>
> > > > }
>
> > > > class Comodidad {
>
> > > > }
>
> > > > class AsignacionComodidad {
> > > > Habitacion habitacion;
> > > > Comodidad comodidad;
> > > > TimeSpan periodo;
>
> > > > }
>
> > > > Este modelo te pemite obtener estadisticas independientemente de que la
> > > > comodidad se encuentre asociada o no y, ciertamente, no requiere una
> > > > relacion bidireccional.
>
> > > > ----------------------------------
> > > > Carlos Peix
>
> > > > 2009/11/17 Gastón Nola Alonso <gnol...@gmail.com>
>
> > > > > Hola gente, les planteo la situación y problema
>
> > > > > Estoy modelando un hotel; el mismo tiene habitaciones y éstas a
> > > su
> > > > > vez un conjunto de comodidades. Una misma comodidad puede estar en
> > > > > varias habitaciones al mismo tiempo.
>
> > > > > En código esto se tradujo como una clase Hotel (no
> > > > > persistente),
> > > una
> > > > > clase Habitacion con un set de comodidades, y una clase Comodidad con
> > > > > un set de habitaciones. El motivo de hacer esta relación bidireccional
> > > > > es el de permitir eliminar una Comodidad tan solo si no hay
> > > > > habitaciones utilizándola (y quizás en un futuro para realizar
> > > > > estadísticas sobre porcentaje de uso, etc).
>
> > > > > En la base de datos, creé una tabla para cada clase y una
> > > tercera,
> > > > > Habitaciones_Comodidades, para guardar la relación. En lugar de
> > > > > utilizar las claves foráneas como PK, hice que la tabla tuviera su
> > > > > propio ID para cada relación.
>
> > > > > La secciones relevantes de los archivos de mapeo son:
>
> > > > > //En Comodidad
> > > > > ...
> > > > > <set name="Habitaciones" table="Habitaciones_Comodidades">
> > > > > <key column="ID"/>
> > > > > <many-to-many class="Habitacion" column="IDHabitacion"/>
> > > > > </set>
> > > > > ...
>
> > > > > //En Habitación
> > > > > ...
> > > > > <set name="Comodidades" table="Habitaciones_Comodidades">
> > > > > <key column="ID"/>
> > > > > <many-to-many class="Comodidad" column="IDComodidad"/>
> > > > > </set>
> > > > > ...
>
> > > > > Y en las POCO:
>
> > > > > //En Habitación
>
> > > > > public Habitacion (ISet<Comodidad> comodidadesP, int numeroP,
> > > String
> > > > > capacidadP, String categoriaP){
>
> > > > > this.Numero = numeroP;
> > > > > this.Capacidad = capacidadP;
> > > > > this.Categoria = categoriaP;
> > > > > this.EstaOcupada = false;
> > > > > Comodidades = new HashedSet<Comodidad>();
>
> > > > > foreach (Comodidad c in comodidadesP)
> > > > > {
> > > > > this.agregarComodidad(c);
> > > > > }
> > > > > }
>
> > > > > public virtual bool agregarComodidad(Comodidad comodidadP){
> > > > > bool agregado = false;
> > > > > if (!Comodidades.Contains(comodidadP)){
> > > > > Comodidades.Add(comodidadP);
> > > > > comodidadP.agregarHabitacion(this);
> > > > > agregado = true;
> > > > > }
> > > > > return agregado;
> > > > > }
>
> > > > > //En Comodidad
>
> > > > > public virtual void agregarHabitacion(Habitacion hab)
> > > > > {
> > > > > if (!Habitaciones.Contains(hab))
> > > > > {
> > > > > Habitaciones.Add(hab);
> > > > > }
> > > > > }
>
> > > > > El problema surge al querer guardar una Habitacion (la Comodidad la
> > > > > guarda sin problemas), porque recibo esta excepción:
>
> > > > > GenericAdoException
> > > > > {"could not insert collection rows: [Dominio.Comodidad.Habitaciones#2]
> > > > > [SQL: INSERT INTO Habitaciones_Comodidades (ID, IDHabitacion) VALUES
> > > > > (@p0, @p1)]"}
>
> > > > > InnerException
> > > > > {"No se puede insertar el valor NULL en la columna 'IDComodidad',
> > > > > tabla 'C:\\DOCUMENTS AND SETTINGS\\ADMINISTRADOR\\MIS DOCUMENTOS\
> > > > > \VISUAL STUDIO 2008\\PROJECTS\\PROYECTO\\BIN\\DEBUG\
> > > > > \DBHOTEL.MDF.dbo.Habitaciones_Comodidades'. La columna no admite
> > > > > valores NULL. Error de INSERT.\r\nSe terminó la instrucción."}
>
> > > > > ¿A que se debe?
>
>
--~--~---------~--~----~------------~-------~--~----~
Para escribir al Grupo, hágalo a esta dirección:
NHibernate-Hispano@googlegroups.com
Para más, visite: http://groups.google.com/group/NHibernate-Hispano
-~----------~----~----~----~------~----~------~--~---