José, muchísimas gracias por el gráfico y por el enlace :) La verdad es que es impresionante lo que se puede hacer, la flexibilidad es increíble.
En cuanto a los tipos de dato, eso si que no me importa, serían string (varchar en la BD) ya que son datos definidos por el usuario no hace falta mucho más. En fin, veo estoy muy muy verde todavía, creo que tengo que cambiar mi forma de pensar y leer bastante documentación para no dar palos de ciego. Muchas gracias a todos. On 24 nov, 02:32, José F. Romaniello <[email protected]> wrote: > <map /> es realmente interesante. Tanto el key como el value pueden ser > element (string, int ,...), component, o un entity. > Hay mas información > aca:http://ayende.com/Blog/archive/2009/06/03/nhibernate-mapping-ndash-lt... > > Una opción podría ser así, gráficamentehttp://screencast.com/t/WVGzHvNyh3dn > > Las clases: > public class TipoExpediente : EntityBase > { > ... > public virtual string Nombre{get;set;} > public virtual ICollection<string> AttributosPosibles {get {return > _attributosPosibles; } } > > } > > public class Expediente : EntityBase > { > public virtual DateTime Fecha{get;set;} > public virtual TipoExpediente{get;set;} > public virtual IDictionary<string, string> Attributos{get....} > > } > > Los mappings: > > <class name="TipoExpediente"> > > <id name="ID"> > > <generator class="hilo"> > > </generator> > > </id> > > <property name="Nombre"/> > > <set name="AttributosPosibles" > > access="field.camelcase-underscore"> > > <key> > > <column name="TipoExpedienteID"/> > > </key> > > <element type="System.String" /> > > </set> > > </class> > > <class name="Expediente"> > > <id name="ID"> > > <generator class="hilo"> > > </generator> > > </id> > > <property name="Fecha"/> > > <many-to-one name="TipoExpediente" /> > > <map name="Attributos" > > table="Expediente_Attributos"> > > <key> > > <column name="ExpedienteID"/> > > </key> > > <map-key type="System.String" /> > > <element type="System.String" /> > > </map> > > </class> > > De ahí en adelante la podes complicar muchisimo más usando componentes o > clases en los key y en los value. También he visto que a veces se predefinen > cosas como rangos, o valores posibles. > > Solamente una cosa tenes que tener presente, al llegar.............. a la > base de datos un número es un número, un texto es un texto y un datetime es > un datetime. > Guardar números o fechas en un campo de texto es algo que pensaría 100 > veces. > > El 23 de noviembre de 2010 20:50, Nestor Rodriguez > <[email protected]>escribió: > > > > > > > > > Si podria ser un <map>, pero la pregunta mas alla de como lo mapeas a > > tablas es como lo modelaste en tu negocio ?. Ademas, que tipos de datos vas > > a almacenar? son todos string? o numeros tambien ? > > > 2010/11/23 Fabio Maulo <[email protected]> > > >> o talz una mas simple y comunacha <map> > > >> 2010/11/23 Fabio Maulo <[email protected]> > > >> dynamic-componets or dynamic-entities or schema-less-component > > >>> 2010/11/23 tolemaC <[email protected]> > > >>>> Nestor el usuario se define sus propios campos para cada tipo de > > >>>> expediente, tengo una tabla TipoExpediente con su Id, su Nombre y > >>>> Descripción, el usuario puede crear nuevos tipos. Luego tengo la tabla > >>>> de Expedientes donde hay un campo IdTipo, al crear el expediente el > >>>> usuario selecciona un tipo. Entonces a la hora de editar dicho > >>>> expediente hay unos datos adicionales que se asocian al tipo en > >>>> concreto que el usuario a creado. > > >>>> Para hacer "table per hierarchy" debería prever todos los tipos que el > >>>> usuario se puede crear, eso es inviable. > > >>>> Lo único que se me ocurre es montarme un EAV (Entidad Atributo Valor) > >>>> por un lado crearme una tabla con la descripción de los datos > >>>> asociados al tipo con: IdTipo, NombreCampo > >>>> Y por otro lado una tabla para almacenar los valores con: Id > >>>> Expediente, Nombre Campo, Valor > > >>>> Miraré otra vez el dynamic-component, pero por lo que he visto > >>>> necesitas conocer cuales serán los campos. > > >>>> On 23 nov, 20:16, Nestor Rodriguez <[email protected]> wrote: > >>>> > Aunque no entiendo del todo tu problema sobre todo cuando dices: > >>>> > *"No me vale el tener que crear una entidad Expediente para cada > >>>> "Tipo > >>>> > de Expediente"*" > >>>> > Te recomiendo que verifiques si un dynamic-component se aplica a tu > >>>> caso > >>>> > donde las propiedades dinamicas son guardadas en un diccionario y en > >>>> la BD > >>>> > son columnas de la tabla. Sin embargo creo que si tienes diferentes > >>>> tipos > >>>> > de expedientes deberias tenerlos como clases que extienden de una > >>>> abstracta > >>>> > o interfaz TipoExpediente y mapearlo en una herencia "table per > >>>> hierarchy". > > >>>> > Saludos, > >>>> > Nestor Rodriguez > > >>>> > 2010/11/23 tolemaC <[email protected]> > > >>>> > > Hola de nuevo. > > >>>> > > Tengo algo en mente que no tengo muy claro como plantearlo para > >>>> > > trabajar con NHibernate y me gustaría me diesen su opinión. > > >>>> > > Tengo un caso donde me haría falta que ciertas entidades tuvieran > >>>> > > campos dinámicos. > > >>>> > > Por ejemplo en mi aplicación hay una entidad para los Expedientes, > >>>> > > dichos expedientes tienen una propiedad que es el "Tipo de > >>>> Expediente" > >>>> > > y los usuarios son libres de crear los tipos de expedientes que > >>>> > > quieran. Aquí es donde surge una particularidad, resulta que cada > >>>> tipo > >>>> > > de expediente que los usuarios se crean pueden tener unos datos > >>>> > > adicionales, por ejemplo un expediente de tipo "Obra o servicio" > >>>> tiene > >>>> > > campos adicionales como es el "Contratista" que realiza la obra o > >>>> > > servicio, un expediente de tipo "Sanción a empleado" tiene un dato > >>>> > > asociado que es el Empleado sancionado, ... y así sucesivamente. > > >>>> > > No me vale el tener que crear una entidad Expediente para cada "Tipo > >>>> > > de Expediente", pues el usuario debe poder crearse nuevos tipos de > >>>> > > expediente cuando quiera sin mi intervención y ademas al tipo de > >>>> > > expediente le debe poder relacionar esos datos/campos/propiedades > >>>> > > extra. > > >>>> > > Se os ocurre como plantear este tema usando NHibernate? > > >>>> > > -- > >>>> > > Para escribir al Grupo, hágalo a esta dirección: > >>>> > > [email protected] > >>>> > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano > > >>>> -- > >>>> 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 > > >> -- > >> 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 > > > -- > > Para escribir al Grupo, hágalo a esta dirección: > > [email protected] > > Para más, visite:http://groups.google.com/group/NHibernate-Hispano -- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano
