Pergunta

Tenho uma pergunta que posso estar pensando demais neste momento, mas aqui vai...

Tenho 2 classes de Usuários e Grupos.Usuários e grupos têm um relacionamento muitos para muitos e eu estava pensando que a tabela de junção group_users eu queria ter uma propriedade IsAuthorized (porque alguns grupos são privados - os usuários precisarão de autorização).

Você recomendaria criar uma classe para a tabela de junção, bem como para a tabela de usuários e grupos? Atualmente minhas aulas estão assim.

public class Groups
{
    public Groups()
    {
        members = new List<Person>();
    }
    ...
    public virtual IList<Person> members { get; set; }
}

public class User
{


    public User()
    {
       groups = new Groups()
    }
    ...
    public virtual IList<Groups> groups{ get; set; }

}

Meu mapeamento é semelhante ao seguinte em ambas as classes (estou mostrando apenas aquele no mapeamento de usuários, mas eles são muito semelhantes):

HasManyToMany<Groups>(x => x.Groups)
.WithTableName("GroupMembers")
.WithParentKeyColumn("UserID")
.WithChildKeyColumn("GroupID")
.Cascade.SaveUpdate();

Devo escrever uma classe para a tabela de junção semelhante a esta?

public class GroupMembers
{
    public virtual string GroupID { get; set; }
    public virtual string PersonID { get; set; }
    public virtual bool WaitingForAccept { get; set; }
}

Eu realmente gostaria de poder ajustar o status de membro do grupo e acho que estou tentando pensar na melhor maneira de fazer isso.

Foi útil?

Solução

Geralmente gosto apenas de criar classes que representem entidades comerciais reais.Nesse caso, não acho que 'membros do grupo' represente algo de valor no seu código.Para mim, o ORM deve mapear o banco de dados para seus objetos de negócios.Isso significa que suas classes não precisam espelhar exatamente o layout do banco de dados.

Também suspeito que, ao implementar GroupMembers, você acabará com algumas coleções desagradáveis ​​nas classes de usuário e de grupo.I.E.a classe de grupo terá a lista de usuários e também uma lista de membros do grupo que faz referência a um usuário e vice-versa para a classe de usuário.Para mim, isso não é tão limpo e tornará mais difícil manter e propagar alterações nas tabelas.

Eu sugeriria manter a tabela de junção no banco de dados como você sugeriu, e adicionar uma lista de grupos chamados waittoaccept em usuários e (se também fizer sentido) adicionar uma lista de usuários chamados waittoaccept em grupos.

Eles então extrairiam seus valores de sua tabela de junção no banco de dados com base no sinalizador waittoaccept.

Outras dicas

Sim, claro que você precisa de outra classe como UserGroupBridge.Outro bom efeito colateral é que você pode modificar a associação de usuários e membros de grupos sem carregar objetos de usuário/grupo potencialmente pesados ​​na sessão do NHibernate.

Saúde.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top