Como lidar com um muitos-para-muitos em minha API

Question

Eu tenho duas entidades foo e bar com muitos para muitos relação entre eles.

Vamos dizer que não há argumento semântico para por Foo pode ser "responsável" pelo relacionamento muitos para muitos, mas nós decidir arbitrariamente que Foo é responsável pela relação (Ie, em NHibernate que marcaria Bar como Inverse)

Isso é tudo muito bem do ponto de vista DB, mas meus APIs entidade revelam um problema.

    // Responsible for the relation
    public class Foo
    {
        List<Bar> Bars = new List<Bar>();

        public void AddBar(Bar bar)
        {
            Bars.Add(bar);
            bar.AddFoo(this);
        }
    }

    public class Bar
    {
        List<Foo> Foos = new List<Foo>();

        // This shouldn't exist.
        public void AddFoo(Foo foo)
        {
            Foos.Add(foo);
            foo.AddBar(this); // Inf Recursion
        }
    }

Se nós decidimos que Foo é responsável por essa relação, como faço para atualizar a coleção associada em Bar sem criar um método Bar.AddFoo pública () que nem deveria existir?

Eu sinto que eu deveria ser capaz de manter a integridade do meu modelo de domínio, sem recorrer a ter que recarregar essas entidades do DB após uma operação como esta.

UPDATE: Código emenda inspirado pelo comentarista.

Answer 1

Você disse que um lado vai "próprio" do relacionamento. Tornar público este método. As outras associações (ou adicionar métodos) pode ser feita interna para os consumidores a evitar de interagir com ele diretamente.

public class Foo
{  
   private IList<Bar> Bars {get;set;}

   public void AddBar(Bar bar)
   {
      Bars.Add(bar);
      bar.Foos.Add(this);
   }
}

public class Bar
{
   internal IList<Foo> Foos {get;set;}
}

Answer 2

Você pode estar faltando um conceito de domínio lá. Você já tentou criar uma terceira entidade:? FooBarRelationship

Answer 3

trabalhando ligações bi-direcional na documentação do Hibernate.

Muitos desenvolvedores programar defensivamente e criar métodos de gestão apontam para definir correctamente ambos os lados, v.g. no Pessoa:

protected Set getEvents() {
    return events;
}

protected void setEvents(Set events) {
    this.events = events;
}

public void addToEvent(Event event) {
    this.getEvents().add(event);
    event.getParticipants().add(this);
}

public void removeFromEvent(Event event) {
    this.getEvents().remove(event);
    event.getParticipants().remove(this);
}

Eu pessoalmente acho Entidade objeto segurando a lista de objeto relacionado está sendo muito inteligente, e você deve deixar o DAL bater o banco de dados.

DALFactory.FooAdapter.getBars(foo);

Answer 4

você poderia torná-lo estático

public class Foo
{
    List<Bar> Bars = new List<Bar>();

    public void AddBar(Bar bar)
    {
        Bars.Add(bar);
        Bar.AddFoo(bar,this);
    }
}

public class Bar
{
    List<Foo> Foos = new List<Foo>();

    // This shouldn't exist.
    public static void AddFoo(Bar bar, Foo foo)
    {
        bar.Foos.Add(foo);
        //foo.AddBar(this); inf recurtion
    }
}

Não é realmente ideal, mas ele faz obter a função fora do objeto sua auto