Um dos recursos muito esperados do Entity Framework 4 é a capacidade de usar o POCO (Plain Old CLR Objects) de maneira ignorante à persistência (ou seja, eles não "sabem" que estão sendo persistentes com o Entity Framework versus um outro mecanismo) )

Estou tentando entender por que é necessário executar correções de associação e usar FixupCollection no meu objeto de negócios "simples". Esse requisito parece implicar que o objeto de negócios não pode ignorar completamente o mecanismo de persistência (afinal, a palavra "correção" parece que algo precisa ser corrigido / alterado para funcionar com o mecanismo de persistência escolhido).

Especificamente, estou me referindo à região Association Fixup que é gerada peloGerador de entidades ADO.NET POCO, por exemplo.:

    #region Association Fixup

    private void FixupImportFile(ImportFile previousValue)
    {
        if (previousValue != null && previousValue.Participants.Contains(this))
        {
            previousValue.Participants.Remove(this);
        }

        if (ImportFile != null)
        {
            if (!ImportFile.Participants.Contains(this))
            {
                ImportFile.Participants.Add(this);
            }
            if (ImportFileId != ImportFile.Id)
            {
                ImportFileId = ImportFile.Id;
            }
        }
    }

    #endregion

bem como o uso de FixupCollection. Outros ORMs ignorantes à persistência comuns não têm restrições semelhantes.

Isso se deve a decisões fundamentais de design na EF? Existe algum nível de não ignorância aqui para permanecer nas versões posteriores da EF? Existe uma maneira inteligente de ocultar essa dependência de persistência do desenvolvedor do POCO?

Como isso funciona na prática, de ponta a ponta? Por exemplo, eu entendo que o suporte foi adicionado recentemente apenas ao ObservableCollection (necessário para o Silverlight e o WPF). Há outras dicas em outras camadas de software dos requisitos de design de objetos POCO compatíveis com EF?