c# - fluently - Configurando una relación de muchas personas con Fluent Nhibernate

nhibernate c#

Question

Estoy discutiendo un poco con mi compañero de trabajo y parece que todavía no puedo encontrar una respuesta. Esto es muy básico.

Estableciendo una relación uno a muchos en la entidad Fluent Nhibernate.

Tomemos Roles y usuarios, por ejemplo. Se puede asignar un rol a múltiples usuarios, así que hice que mi entidad tenga las siguientes características:

public class User
{
[Required]
public virtual string FirstName { get; set; }
public virtual Role Role { get; set; }
}

y rol

public class Role
{
[Required]
public virtual string Name { get; set; }
public virtual IList<User> Users{ get; set; }
public Role()
{
Users = new List<Users>();
}
}

Como puede ver, estoy haciendo referencia a una colección de usuarios en roles, como decir que cada función tendrá múltiples usuarios. La entidad de usuario tiene esa referencia de entidad de función necesaria para identificar a qué función pertenece un usuario.

En mi opinión, esta es la forma correcta de vincular y mi compañero de trabajo dice que tener una referencia de Role para los usuarios creará una referencia circular. ¿Quién tiene la razón?

Traté de encontrar la respuesta en línea. Creo que esta pregunta me dice que estoy en lo cierto: fluidez en el mapeo de NHibernate Many to one

Pero luego miré un proyecto de ejemplo de Fuent Nhibernate aquí https://github.com/jagregory/fluent-nhibernate/tree/master/src/Examples.FirstAutomappedProject/Entities y no doy un ejemplo de lo que intento implementar. ¿Pueden aconsejarme o ayudarme a encontrar un documento que explique la forma correcta? ¿Estoy en lo cierto? Gracias.

Answer 1

Lo que está proponiendo aquí es totalmente posible y admisible dentro del marco nHibernate. Obviamente, usted ha enumerado los modelos en lugar de los archivos de mapeo, pero Fluent nHibernate le permite configurar sus mapeos de esta manera sin problemas.

Si realmente eliges mapear una relación de esta manera depende enteramente de las preferencias personales y el escenario específico. He mapeado modelos de esta manera, pero igualmente he decidido no hacerlo, principalmente porque en algunos casos no tiene sentido complicar demasiado el gráfico del objeto. Tomemos, por ejemplo, una tabla de búsqueda (por ejemplo, Cultura o Configuración regional) a la que se hace referencia muchas veces en varias tablas en una base de datos. Al mapear esto, tendría una propiedad Cultura en cada uno de los modelos padres pero no tendría colecciones de objetos padre en el modelo Cultura, simplemente no tiene sentido.

También debe considerar cargar datos a través de su capa de persistencia: si crea este tipo de relación y solo necesita una lista simple de roles que necesita considerar cuando, o si, la colección de usuarios está llena, puede especificar la carga ansiosa o tardía, pero En mi experiencia, la especificación de la carga ansiosa con un comando de recuperación correspondiente en las consultas puede dar como resultado una llamada más optimizada a la base de datos.

Básicamente, lo que estoy diciendo es que no existe una "forma correcta" absoluta a la hora de decidir cómo definir tus mapeos: realmente necesitas equilibrar un modelo de objetos enriquecido con el rendimiento de las consultas, pero tu ejemplo específico es perfectamente aceptable si lo necesitas.

Acabo de volver a leer su pregunta y no estoy seguro si también está pidiendo ejemplos de asignaciones configuradas de esta manera, así que si quiere algunos ejemplos háganmelo saber y lo armaré por usted.

Para lograr la relación que describes necesitarás las siguientes clases de mapas (he añadido propiedades de Id porque supongo que las tienes):

Para los Roles:

public class RoleMap : ClassMap<Role>
{
public RoleMap()
{
Table(@"Roles");
Id(x => x.Id).GeneratedBy.Assigned();
Map(x => x.Name).Column("Name");
HasMany<User>(x => x.Users)
.Inverse()
.KeyColumns.Add("RoleId", mapping => mapping.Name("RoleId"));
}
}

Para los usuarios:

public class UserMap : ClassMap<User>
{
public UserMap()
{
Table(@"Users");
Id(x => x.Id).GeneratedBy.Assigned();
Map(x => x.FirstName);
Map(x => x.RoleId);
References(x => x.Role)
.Class<Role>()
.Columns("RoleId");
}
}

No me gustaría demasiado colgado en "su método vs su método" - lo anterior es perfectamente aceptable, y depende de sus requisitos cuando llegue a utilizar el modelo de objetos en su código. Alternativamente, si no desea una colección de Usuarios en el Mapa de roles, simplemente elimine esa propiedad y la declaración de correlación HasMany asociada. Una cosa a destacar de lo anterior es que la especificación .Inverse () ha delegado la administración de la relación entre un Rol y un Usuario a la entidad Usuarios, lo que tiene sentido básicamente como el proceso de agregar o editar un usuario existente y proporcionar un RoleId forjará la relación.

Espero que esto ayude un poco si tienes preguntas más específicas házmelo saber