I think I understand what you're trying to do. Your relationship is wrong. If a Projeto has N Atividade s, and a Atividade belongs to N Projeto s, you could never use something like this:

public class Atividade : ObjetoPersistente
{

    public Atividade()
    {
        ...
        Projetos = new List<Projeto>();
    }

    ...
    public List<Projeto> Projetos { get; set; }    
    ...
}

So you're saying that Atividade has N Projeto s, but that a Projeto belongs to only Atividade .

The correct one would be:

[Table("tb_atividade")]
public class Atividade : ObjetoPersistente
{

    public Atividade()
    {
        ...
        // Retire isso
        // Projetos = new List<Projeto>();
    }

    ...
    // Não use Projetos diretamente. Use uma tabela associativa.
    public virtual ICollection<ProjetoAtividade> ProjetoAtividades { get; set; }    
    ...
}

Projeto also receives ProjetoAtividades , as it is an association:

[Table("tb_projeto")]
public class Projeto : ObjetoPersistente, IObjetoElementoOption
{       
    ...
    public virtual ICollection<ProjetoAtividade> ProjetoAtividades { get; set; }  
}

Now you also need to map ProjetoAtividade :

[Table("tb_atividade_projeto")]
public class ProjetoAtividade
{
    [Key]
    [Column("fk_atividade")]
    public int AtividadeId { get; set; }

    [Key]
    [Column("fk_projeto")]
    public int ProjetoId { get; set; }

    // Estas são propriedades de navegação.
    // O Entity Framework carrega essas classes automaticamente.
    public virtual Projeto Projeto { get; set; }
    public virtual Atividade Atividade { get; set; }
}

Notice that I do not need to use Fluent API here. I can just decorate the properties with Attributes and the Entity Framework does everything else alone.

Inclusions and Modifications

As the Models mapping is wrong, you will need to map Codigo to the classes to work:

[Table("tb_atividade")]
public class Atividade : ObjetoPersistente
{
    [Key]
    // Não sei se a coluna no banco chama "codigo", mas suponho que sim.
    [Column("codigo")]
    public int Codigo { get; set; }

    ...
}

[Table("tb_projeto")]
public class Projeto : ObjetoPersistente, IObjetoElementoOption
{       
    ...
    [Key]
    // Não sei se a coluna no banco chama "codigo", mas suponho que sim.
    [Column("codigo")]
    public int Codigo { get; set; }
}

About inclusions, to insert a new association, do the following:

// Carregue o projeto
var projeto = contexto.Projetos.FirstOrDefault(p => p.Codigo == /* Coloque o valor da chave aqui */);
// Carregue a atividade
var atividade = contexto.Atividades.FirstOrDefault(a => a.Codigo == /* Coloque o valor da chave aqui */);
if (projeto != null && atividade != null)
{
    var projetoAtividade = new ProjetoAtividade 
    {
        // É assim mesmo que usa. __NUNCA__ defina o Id diretamente.
        Atividade = atividade,
        Projeto = projeto
    }

    contexto.ProjetoAtividades.Add(projetoAtividade);
    contexto.SaveChanges();
}

As the change to the associative entity does not make sense, I'll teach you how to do an exclusion:

var projetoAtividade = contexto.ProjetoAtividades.FirstOrDefault(/* Coloque aqui a condição para selecionar a associação, aqui usando os Ids */);
if (projetoAtividade != null)
{
    contexto.ProjetoAtividades.Remove(projetoAtividade);
    contexto.SaveChanges();
}

Well, a priori you do not have to load related entities at all times. Especially when making changes.

Now, whenever you use a reference to an entity that exists in the database, you need to give attach or retrieve the entities. Do not always search the database, but need to give attach in dbcontext .

Interestingly, I have a question exactly like this in the OS, which did not get an answer (and I had to go back and respond): Question SO .

At first it seems strange: having to recover entities that are already there. But it works that way. Let's say you already have the projects, say returned from the user interface in a web application. Let's also say that you trust that these objects are okay. You could create a new activity and insert these projects, right? No. If you do this, DBContext will actually create new projects, because the ones you are using are not attached .

An alternative way to do this is to give attach and change the entity state to unchanged . So DBContext does not change these projects, but does not change them either.

But deep down, the practice of getting them back into the bank is correct. I do not imagine a scenario where you could have dettached objects that are safe, even if they were previously recovered (possibly GOOD before) could have been removed from the DB.

You can encapsulate this in your repositories, but not generic . It is precisely the fact that each entity has special relationships that makes these logics necessary.