Eu sempre falo que não é a melhor situação do mundo trabalhar com EF em contextos de aplicações distribuidas, ou mesmo em uma onde você não guarde o contexto do EF por muito tempo, como no caso de uma aplicação web onde você guardou uma entidade do EF na sessão, mas não o contexto.

<parêntesis>
Aliás, isso é boa prática: nunca mantenha o contexto na memória muito tempo. As entidades ficam desatualizadas, e o EF faz cache, o que ocupa espaço e mata sua escalabilidade.
</parêntesis>

O Danny Simmons, do time de ADO.Net e que trabalha no EF, é sempre um cara transparente e legal de ler. E agora ele vem deixar claro que não é mesmo muito fácil usar EF nesses contextos de aplicação distribuida. Vale a pena dar uma olhada na solução que ele propõe para o problema.

Mas ele ressalva algo que eu já disse várias vezes: se sua entidade tem relacionamentos, esquece, vai dar problema. Melhor ir no banco, buscar a entidade, atualizá-la, e submeter o update. Não espere ser capaz de recriar a entidade do zero e submeter o update para uma entidade com relacionamentos. Isso vai ser resolvido na versão 2.0 do EF, que vai sair junto com o .Net 4.0, e que eu estou muito ansioso para ver. Nesses cenários ainda é melhor usar NHibernate (pelo menos até a próxima versão do EF, quando vou reavaliar isso).

Veja o blog post dele aqui.